‏بازنویسی یه سرویس ۹۲ میلیون پیامی با Claude Code

تیم Checkly تو بلاگش تعریف کرده که Results Daemon، یعنی همون سرویس پس‌زمینه‌ای که نتیجهٔ مانیتورینگ‌ها رو می‌گیره، تو دیتابیس می‌نویسه، آلارم می‌فرسته و آپدیت‌های WebSocket رو پابلیش می‌کنه، داشت زیر بار کم می‌آورد. این سرویس روزی حدود ۹۲ میلیون پیام پردازش می‌کنه که چهل میلیونش نتیجهٔ چک‌هاست. حجم چک‌های پلتفرم تو یه سال دو برابر شده بود، پس تیم تصمیم گرفت سرویس رو از JavaScript ساده به Go ببره و کدنویسی رو به یه ایجنت بسپره.

جالب اینجاست که تمرکز مقاله روی خود بازنویسی نیست، روی هارنس تسته. به گفتهٔ نویسنده وقتی قراره ایجنت کد بنویسه، یه چیزی غیر از ریویوِ آدم باید تعریف کنه «درست» یعنی چی. پس اول هارنس رو ساختن، بعد سراغ کد رفتن. هارنس کاملاً جعبه‌سیاهه و هیچ وابستگی‌ای به زبان سرویس نداره: خروجی هر تست از سیستم قدیمی گرفته و به‌عنوان golden file ذخیره شده تا نسخهٔ جدید بایت‌به‌بایت باهاش مقایسه بشه. فیلدهای غیرقطعی مثل UUID و timestamp هم با پلیس‌هولدر جایگزین ولی همچنان از نظر نوع بررسی می‌شن.

سه ابزار زیر هارنس نشسته: Playwright، Docker Compose و Toxiproxy (یه پراکسی TCP که خرابی شبکه رو شبیه‌سازی می‌کنه تا رفتار سیستم موقع از کار افتادن زیرساخت تست بشه). سرویس‌های اطراف مثل PostgreSQL واقعی و داخل کانتینر بالا میان نه شبیه‌سازی‌شده، و کلاس‌هایی به اسم oracle خروجی رو چک می‌کنن، مثل PostgresOracle.expectResultToMatchSnapshot(testId). ورودی تست‌ها هم از دیتای واقعی ۲۴ ساعت گذشتهٔ خود پلتفرم ساخته شد تا پوشش کد بین ۹۰ تا ۱۰۰ درصد برسه.

ایجنت یه شب کار کرد و حدود ۱۳ هزار خط کد سرویس قابل‌دیپلوی تحویل داد، اون هم داخل سقف مصرف روزانهٔ یه اشتراک ۲۰۰ دلاری. ولی اولین دیپلوی روی حساب‌های داخلی مشکل داشت و retryها درست کار نمی‌کردن. ریشه‌اش یه سوراخ تو هارنس بود: توپولوژی صف‌ها تو محیط لوکال ساده‌سازی شده بود. لوکال فقط ۳ صف داشت، ولی تو پروداکشن مسیر retry به اولویت و نوع هاستینگ هم وابسته‌ست و در هر ریجن ۱۸ صف داره. ایجنت منطقش رو روی همون مدل غلط ساخته بود.

بعد از اصلاح هارنس و یه ریفکتور با نظارت آدم، مهاجرت مشتری‌ها مرحله‌به‌مرحله با فیچرفلگ انجام شد: اول حساب‌های رایگان، بعد پولی و آخر سازمانی، با ۲۴ تا ۴۸ ساعت مانیتورینگ بین هر مرحله. تو این مدت CI هارنس رو هم روی سرویس قدیمی و هم جدید اجرا می‌کرد تا از هم جدا نیفتن. نویسنده می‌گه سیستم تایپ Go برای کار با ایجنت خیلی بهتر از JavaScript جواب داده و حالا با تکیه بر هارنس، کد نوشته‌شدهٔ ایجنت رو سریع‌تر از قبل منتشر می‌کنن.

نکات کلیدی:

• سرویس روزانه حدود ۹۲ میلیون پیام پردازش می‌کنه؛ چهل میلیونش نتیجهٔ چک و بقیه پابلیش WebSocket.
• ایجنت تو یه شب حدود ۱۳٬۰۰۰ خط کد Go تولید کرد و مصرف توکنش داخل سقف روزانهٔ اشتراک ۲۰۰ دلاری موند.
• یه تلاش قبلی با Opus کیفیت مورد نظر تیم رو نداشت و دور انداخته شد؛ نسخهٔ نهایی با Fable ساخته شد.
• نتیجه: انتشار بدون حادثه، ۷۰ درصد کاهش تعداد پاد، ۶۰ درصد کاهش AAS دیتابیس و حدود ۱۵ درصد کاهش CPU دیتابیس.
• حدود ۱۵ vCPU و ۴۵ گیگابایت رم آزاد شد؛ ابزار sqlc هم کوئری‌های بهینه‌تری تولید کرد.
• بزرگ‌ترین باگ از یه فرض نانوشته تو هارنس اومد: ۳ صف retry تو لوکال در برابر ۱۸ صف در هر ریجن تو پروداکشن.