- +۳۰۰ هزارکاربر یکتا
- ۴۰ هزارکاربر فعال ماهانه در اوج
- +۳ هزارکاربر فعال روزانه
بیش از ۱۰ میلیون درخواست
این ربات باید در دوره‌های پرترافیک هم به درخواست‌ها پاسخ می‌داد. زمان پاسخ و وضعیت صف‌ها معیارهای اصلی برای بررسی عملکرد بودند.
در طول فعالیت سامانه بیش از ۱۰ میلیون درخواست پردازش شد. زیر بار واقعی، صف‌های انباشته، پایان مهلت پاسخ سرویس‌های وابسته و تلاش‌های مجدد هم‌زمان از مسائل اصلی بودند.
طراحی برای بار واقعی
مسیر دریافت update از پردازش اصلی جدا شد تا ورود ناگهانی درخواست‌ها باعث قفل شدن workerها نشود. کارهای سنگین‌تر به صف منتقل شدند و عملیات کوتاه با کمترین وابستگی پاسخ داده می‌شدند.
برای عملیات تکرارشونده cache در نظر گرفته شد و timeoutها مرز مشخص داشتند. retry بدون backoff می‌تواند یک اختلال کوچک را به موج درخواست تبدیل کند؛ بنابراین تلاش مجدد باید محدود، قابل مشاهده و همراه با فاصله افزایشی باشد.
پایش و ردیابی درخواست‌ها
در این مقیاس، log ساده برای پیدا کردن مسئله کافی نیست. هر درخواست باید شناسه قابل ردیابی داشته باشد و متریک‌های latency، نرخ خطا، عمق queue و وضعیت سرویس‌های وابسته در کنار هم دیده شوند.
این داده‌ها کمک می‌کردند تفاوت میان کندی API خارجی، کمبود worker و یک query ناکارآمد پایگاه داده سریع‌تر مشخص شود. monitoring چیزی نبود که بعداً به سیستم اضافه شود؛ بخشی از خود معماری بود.
چیزهایی که از مقیاس یاد گرفتم
- بخش ورودی باید بتواند موج ترافیک را بدون وابستگی مستقیم به پردازش کامل جذب کند.
- retry بدون محدودیت و backoff می‌تواند از خود خطای اولیه خطرناک‌تر باشد.
- cache فقط زمانی مفید است که invalidation و رفتار هنگام miss روشن باشند.
- متریک و tracing باید قبل از اولین incident جدی وجود داشته باشند.
- بهینه‌سازی باید براساس داده واقعی انجام شود، نه حدس درباره bottleneck.
کد این پروژه به‌دلیل ماهیت تجاری آن عمومی نیست.