از این به بعد هر مسئلهای — در مصاحبه یا کار — با همین چهار مرحله حل میشود. مصاحبه ۴۵ دقیقهای را هم همینطور تقسیم کن: ۵ + ۵ + ۲۰ + ۱۵.
مرحله ۱ — فهم مسئله و مرزکشی (۵ دقیقه)
- سؤال بپرس، فرض نکن: دقیقاً کدام قابلیتها؟ (MVP، نه همهچیز)
- مقیاس: چند کاربر؟ DAU؟ نسبت خواندن/نوشتن؟ اندازه دادهها؟
- قیود کیفی: تأخیر هدف؟ سازگاری یا دسترسپذیری؟ (CAP را همینجا روشن کن)
- خروجی مرحله: لیست کوتاه Functional + Non-functional که مصاحبهگر تأیید کرده.
مرحله ۲ — تخمین (۵ دقیقه)
- QPS میانگین و پیک، حجم ذخیرهسازی ۵ ساله، پهنای باند — با اعداد گرد (فصل ۲).
- از تخمین نتیجه معماری بگیر: «۱۰۰:۱ خواندنی → کش محور» — تخمینِ بدون نتیجه، نمایش است.
مرحله ۳ — طراحی سطح بالا (۲۰ دقیقه)
- جعبهها را بکش: Client → CDN/LB → API Gateway → سرویسها → کش/DB/صف.
- برای هر Functional Requirement مسیر داده را تعریف کن: نوشتنِ X کجا میرود؟ خواندنش از کجا؟
- API های اصلی را بنویس (۳-۴ endpoint کلیدی).
- مدل داده: جدولها/کلیدها + انتخاب دیتابیس با دلیل.
مرحله ۴ — عمیقشدن و گلوگاهها (۱۵ دقیقه)
- مصاحبهگر (یا خودت) ۱-۲ جزء را انتخاب کن و عمیق شو: الگوریتم فید؟ شمارنده توزیعشده؟
- گلوگاهیابی: SPOF ها؟ Hot Key؟ حد Shard ها؟ چه چیزی اول میشکند؟
- Trade-off هایت را بلند بگو و گزینه رد شده را هم نام ببر — این تفاوت ارشد و مبتدی است.
نگاشت نیاز → ابزار (برگه تقلب)
| اگر شنیدی… | فکر کن به… |
|---|---|
| خواندن سنگین | Cache + CDN + Read Replica |
| نوشتن سنگین | صف + Wide-Column + Sharding |
| بلادرنگ دوطرفه | WebSocket + Pub/Sub |
| جستجوی متنی | Inverted Index / Elasticsearch |
| پول و موجودی | ACID + Idempotency + دفتر کل |
| فایل حجیم | Object Storage + CDN + آپلود مستقیم |
| نزدیکترینها روی نقشه | Geohash / Quadtree |
| محافظت از سرویس | Rate Limiter + Circuit Breaker |
به زبان ساده
روش حل طراحی سیستم یعنی اول مسئله و عدد را روشن کنیم، بعد جعبهها را با دلیل به هم وصل کنیم.
مثال واقعی
برای یک سامانه رأیگیری، ابتدا QPS و دقت لازم را میپرسیم؛ بعد میفهمیم Redis برای شمارش زنده و Kafka برای ثبت پایدار مناسب است.