بازگشت به کتابخانهکتابخانه2.2تخمین ظرفیت (Back-of-envelope)
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 2.2فصل ۲Scalability و ظرفیت

تخمین ظرفیت (Back-of-envelope)

  • ~۱۲ دقیقه
  • ۴ پرسش
  • متن را انتخاب کن تا هایلایت شود

قبل از اینکه برای فروشگاه انبار اجاره کنی، روی کاغذ حساب می‌کنی: روزی چند جعبه می‌آید؟ پنج سال دیگر قفسه‌ها جا دارند؟ دقت گرم نیست؛ می‌خواهی بفهمی مسئله کیلوست یا تن. در طراحی سیستم به این کار می‌گویند Back-of-envelope.

هدف تخمین، دقت اعشار نیست. هدف Order of Magnitude است: صد درخواست در ثانیه است یا صد هزار؟ ده گیگابایت است یا ده پتابایت؟ همین مرتبه، ابزار را عوض می‌کند.

انبار و شمارش جعبه روی کاغذ
مدیر با دفترچه می‌شمارد؛ کارگر جعبه می‌چیند. قبل از اجاره انبار بزرگ‌تر، روی کاغذ معلوم می‌شود جا هست یا نه — همان Back-of-envelope.

اعدادی که هر طراح از حفظ است

این جدول فیزیک است، سلیقه نیست. معماری مدرن از همین اختلاف سرعت‌ها ساخته شده. اگر این مرتبه‌ها را ندانی، Cache و CDN برایت اسم لوکس می‌مانند، نه جواب یک عدد.

عملیاتزمان تقریبی
خواندن از RAM~100ns
خواندن SSD~100µs
Seek دیسک چرخان~10ms
رفت‌وبرگشت داخل یک دیتاسنتر~0.5ms
رفت‌وبرگشت بین قاره‌ها~150ms
فشرده‌سازی 1KB~10µs

نتیجه: RAM هزاربرابر SSD و SSD صدبرابر دیسک سریع‌تر است — پس Cache می‌سازیم. رفت‌وبرگشت بین‌قاره‌ای سیصد برابر داخل دیتاسنتر است — پس CDN و چند-Region می‌سازیم. فیزیک را دور نمی‌زنی؛ داده را نزدیک می‌کنی.

فرمول‌های سریع

این‌ها را مثل متر خیاطی ببین. دقیق نیستند؛ برای بریدن پارچه کافی‌اند.

  • یک روز ≈ 86,400 ثانیه ≈ 10⁵ ثانیه. برای تخمین سرانگشتی همین 10⁵ کافی است.
  • 1M درخواست در روز ≈ 12 QPS میانگین. Peak را دو تا پنج برابر میانگین بگیر.
  • 1M کاراکتر متن ≈ 1MB. یک عکس موبایل ≈ 300KB تا 3MB.
  • ذخیره پنج‌ساله = روزانه × 365 × 5 × ضریب Replication — معمولاً ×3.

مثال حل‌شده: سرویس اشتراک عکس

فرض کن 10M DAU داری. هر کاربر روزی دو عکس یک‌مگابایتی آپلود می‌کند و بیست عکس می‌بیند. بلند حساب کن، گرد کن، بعد ببین عدد چه معماری‌ای را اجباری می‌کند.

  • QPS آپلود: 20M ÷ 10⁵ ≈ 200 میانگین → Peak500 تا 1000.
  • QPS خواندن: 200M ÷ 10⁵ ≈ 2,000 میانگین → Peak ≈ 5,000 تا 10,000. سیستم Read-Heavy است.
  • Storage روزانه: 20M × 1MB = 20TB. پنج‌ساله با ×3 Replication ≈ 110PB. Object Storage و CDN اجباری‌اند، نه یک دیسک روی Server.
  • نسبت خواندن به نوشتن 10:1 است. پول را روی Cache و CDN بگذار، نه فقط روی یک دیتابیس قوی‌تر.

به زبان ساده

Back-of-envelope یعنی قبل از اجاره انبار، روی کاغذ بفهمی مسئله کیلوست یا تن. دقت اعشار نیست؛ Order of Magnitude است.

مثال واقعی

۲۰ میلیون عکس یک‌مگابایتی در روز یعنی حدود ۲۰TB؛ همین عدد می‌گوید عکس را در دیتابیس معمولی نگذار.

دانش‌سنجی

آزمون درس

۴ Q
01
سرویسی 100M درخواست در روز دارد. QPS میانگین حدوداً چند است؟
02
چرا «رفت‌وبرگشت بین‌قاره‌ای ~150ms» به ساخت CDN منجر شد؟
03
نسبت خواندن به نوشتن 100:1 چه پیامی برای معماری دارد؟
04
20M عکس 1MB در روز، پنج سال با Replication ×3 حدوداً چقدر فضا می‌خواهد؟