پاسخ خوب فقط چند جعبه و فلش نیست. باید معلوم کند دقیقاً چه مسئلهای را حل میکنی، با چه تعداد کاربر، داده از کجا رد میشود، هنگام خرابی چه میشود و کدام قابلیتها را فعلاً عمداً نمیسازی.
| بخش پاسخ | معیار قبولی |
|---|---|
| نیازمندی | MVP، خارج از محدوده، SLO، consistency و privacy روشن |
| تخمین | QPS پیک، storage/bandwidth، رشد و فرضها قابل چالش |
| طراحی | مسیر write/read، API و data model برای نیازهای اصلی |
| درستی | idempotency، transaction/constraint، ترتیب و failure semantics |
| عملیات | SLO، metric، alert، rollout، DR و cost trigger |
| Trade-off | حداقل یک گزینه ردشده با دلیل و مسیر رشد 10× |
تمرین زماندار
- ۵ دقیقه: سؤال و فرضها را بنویس؛ اگر فرض بدون تأیید معماری را عوض میکند، آن را explicit کن.
- ۱۰ دقیقه: تخمین و bottleneck غالب؛ اعداد گرد و واحدها را بنویس.
- ۲۰ دقیقه: یک happy path و یک failure path را تا storage دنبال کن.
- ۱۰ دقیقه: دو deep dive (مثلاً reservation و fanout) + SLO/rollout.
- ۵ دقیقه: طرح را با rubric بالا نقد کن: SPOF، data loss، cost و پیچیدگی بیدلیل.
به زبان ساده
پاسخ خوب طراحی یعنی روشن بودن مسئله، عدد، مسیر داده و رفتار هنگام خرابی — نه فهرستکردن ابزارهای مد روز.
مثال واقعی
بهجای «Kafka و Redis میگذارم» بگو: «کاربر باید نتیجه ثبت سفارش را زیر ۲ ثانیه ببیند، پس سفارش در دیتابیس ثبت میشود و پیامک با outbox به صف میرود» — دلیل، تصمیم را میسازد.