«سریع» بدون عدد معنی ندارد. باید بدانیم چند کاربر همزمان داریم، پاسخ قابلقبول چند میلیثانیه است و در چه نقطهای صفها شروع به رشد میکنند. بعد با آزمایش کنترلشده همان فشار را شبیهسازی میکنیم، پیش از آنکه کاربران واقعی مشکل را کشف کنند.
Little’s Law
L = λW: تعداد کارهای در سیستم برابر نرخ ورود ضرب در زمان انتظار است. queue طولانی یعنی latency یا arrival rate مسئله دارد.
Utilization
وقتی یک resource نزدیک ۱۰۰٪ است، صف و tail latency غیرخطی رشد میکنند؛ ۷۰–۸۰٪ headroom عملی لازم است.
Load / stress / soak
load در بار هدف، stress تا شکست، و soak در زمان طولانی برای leak/fragmentation انجام میشود.
Tail latency
در fan-out، p99 کل از کندترین dependency متاثر میشود؛ timeout budget، hedging محدود و کاهش fan-out مهماند.
Cost unit
هزینه را به واحد محصول وصل کن: هزینه هر سفارش، هر GB ذخیرهشده، هر ۱k درخواست یا هر کاربر فعال.
برنامه آزمایش قابل دفاع
- سناریوی production-like، داده و نسبت read/write واقعی تعریف کن؛ تست فقط hit کردن یک endpoint نیست.
- success criteria: error rate، p95/p99، queue lag، saturation و هزینه را از قبل تعیین کن.
- fault injection: کندی DB، از دسترفتن node، پیام تکراری و dependency timeout را در محیط امن تمرین کن.
- بعد از هر تست، bottleneck و فرض را ثبت کن؛ capacity plan با trigger قابل اقدام بساز، نه یک عدد سرور.
به زبان ساده
«سریع» بدون عدد حرف نیست؛ صف جلوی هر بخش کند رشد میکند و هزینه باید به واحد محصول (مثلاً هزینه هر سفارش) وصل شود.
مثال واقعی
اگر هر دقیقه ۱۰۰ سفارش غذا برسد و آشپزخانه ۸۰ تا آماده کند، صف هر دقیقه ۲۰ تا بزرگتر میشود؛ این همان قانون Little است و جوابش همیشه «سرور بیشتر» نیست.