تجربهٔ واقعیِ system design ندارم — از کجا شروع کنم؟

سه منبعِ عملی: ۱) کتابِ طراحیِ معروف (DDIA — Designing Data-Intensive Applications) با خواندنِ آهسته — حتی دو فصلِ اول، نصفِ واژگانِ این درس را عمیق میکند. ۲) تمرینِ «طراحیِ بلند به خودت»: هر سرویسی که روزانه استفاده میکنی (اسنپفود، تلگرام) را ده دقیقه با بلوکهای این درس توضیح بده — به خودت یا به اپِ مکالمهٔ آپورد. ۳) دیالوگِ همین درس را با نقشِ تو حفظ کن: چارچوبِ گفتاری، نصفِ نمره است.

مصاحبهگر وسطِ حرفم مسیر را عوض کرد — چه کنم؟

خوشحال باش — یعنی درگیرِ گفتگو شدی! جوابِ چابک: **"Good point — that changes the storage layer. Let me redo that piece."** و بعد از بازسازی، جمعبندِ کوچک: **"So the new constraint is X — I've adjusted the cache strategy accordingly."** تغییرِ مسیرِ وسطِ جلسه، اتفاقِ طراحیِ واقعی است؛ نشاندادنِ «انعطافِ بازطراحی» همان چیزی است که تیمهای واقعی روزی چند بار انجام میدهند و مصاحبهگر میخواهد ببیند.

درس ۶۲ از ۹۰ · مصاحبهٔ فنی ۲؛ system design از «یک میلیون کاربر» به بالا

system design، مصاحبهٔ «معماریِ گفتاری» است: هیچ کدی نوشته نمی‌شود؛ تو و مصاحبه‌گر روی تخته‌سفید (یا Excalidraw) یک سیستم می‌کشید و می‌سازید. برای زبانِ دوم، خبرِ خوب این است که واژگانش بسته و ثابت است — ده-پانزده بلوک که همهٔ سوال‌ها با آن‌ها ساخته می‌شوند — و سخت‌ترین بخش، «صحبتِ پیوسته در حینِ طراحی» است که قالب‌های همین درس می‌سازندش.

این درس یک سوالِ معروف (URL shortener) را کامل طی می‌کند؛ چارچوبِ گفتاری برای ۹۰٪ سوال‌های دیگر همین است: چون همهٔ سیستم‌ها، همان بلوک‌ها را با اعدادِ متفاوت می‌چینند.

گام ۱؛ نیازمندی‌ها و scale — سوال قبل از طرح

قالبِ آغاز: "Let me clarify the requirements first. Functional: users submit a long URL and get a short one; redirects should work forever. Non-functional: low latency on redirect — that's the hot path. Scale: how many reads are we talking about? 100 million redirects a day is ~1,000 per second — that's actually modest." (اول نیازمندی‌ها رو روشن کنم… ۱۰۰ میلیون ریدایرکت در روز یعنی حدهٔ ۱۰۰۰ در ثانیه — در واقع ناچیز است.) — این پاراگرافِ آغازین، امتیازِ کلِ گامِ اول است: تو داری «مسئله را تعریف» می‌کنی، و مصاحبه‌گر دنبالِ همین سیگنال است. اعداد را بلند بگو و جمع‌بندی کن: "So we're read-heavy — 100 reads per write. That shapes everything." (خوانا-محوره — صد خواندن به‌ازایِ هر نوشتن. این همه‌چیز رو شکل می‌ده.)

گام ۲؛ بلوک‌ها — طراحیِ واژه‌به‌واژه

بلوک	جملهٔ معرفی‌اش	چرا می‌آید
API layer	The API receives the create request and validates it.	درِ ورودی
ID generator	We need short IDs — base62 of a counter, or a hash.	شناسهٔ کوتاه
Database	A key-value store fits: short ID → long URL.	نگه‌داریِ نگاشت
Cache	Hot URLs should never hit the DB — Redis in front.	خواناییِ سریع
Load balancer	LB in front of the API tier, stateless behind it.	پخشِ بار
Queue	Analytics can be async — drop events in a queue.	کارِ پشتِ صحنه
CDN	Not much to cache here — mostly for any static pages.	رسانهٔ ایستا

جمله‌های اتصالِ بلوک‌ها — موتورِ گفتاریِ تو: "So the flow is: the client hits the LB, the LB routes to an API node, the node checks Redis first, falls back to Postgres, and returns the redirect." و برای هر تصمیم، trade-off بگو: "Base62 counter gives short, sortable IDs but a single point of failure — I'd shard the counter or use Snowflake-style IDs. Trade-off: a bit more complexity for availability." — کلمهٔ «trade-off» را نچپانی؛ همان چیزی است که مصاحبه‌گر دنبالش می‌گردد.

گام ۳؛ رشد، خرابی و جمع‌بندی

سوال‌های گامِ آخر که خودت طرح کن (امتیازِ senior): "What breaks at 100x? The DB — I'd shard by ID hash." (چی می‌شکنه اگر صد برابر شود؟ دیتابیس — hash-ID شارد می‌کنم.) · "Single region or multi? Multi-region adds replication lag — for a redirector, eventual consistency is fine." و فنّ بقای مشهور — "There's no single right answer here — it depends on the read/write ratio and the ops budget." جملهٔ «بسته به…» در system design حکمِ «بستنی در گرما» را دارد: هر جا شک کردی، trade-off را با «بسته به» بگو و دو گزینه با قیاس بیاور — همین، پاسِ صحیحِ ۹۰٪ سوال‌هاست. جمع‌بندیِ پایانی: "So: stateless API tier, Redis cache for the hot path, sharded KV store, async analytics. Happy to go deeper on any piece."

If I had more time, I'd dig into the ID generator — that's the most interesting trade-off in this design.اگه وقت بیشتری بود، می‌رفتم سراغِ تولیدکنندهٔ ID — جالب‌ترین trade-off این طراحیه.

گرامرِ عمیق‌تر: زبانِ trade-off و مقیاس

طراحیِ سیستم، زبانِ بسته به و سپردن است: It depends on the read/write ratio (به نسبتِ خواندن/نوشتن بستگی داره), I'd shard by user ID (شناسهٔ کاربر شارد می‌کنم), We accept eventual consistency for availability (برای دسترس‌پذیری، سازگاریِ نهایی رو قبول می‌کنیم). اعدادِ مقیاس: QPS (queries per second), p99 latency (تأخیرِ ۹۹ درصدی), read-heavy / write-heavy (خوانا-محور/نوشتا-محور). و فعل‌های محبوب: scale horizontally (افقی مقیاس کن — ماشینِ بیشتر), cache aggressively (جسورانه کش کن), degrade gracefully (افتِ مؤدبانه — وقتی قطعه‌ای خوابد، کل نمی‌خوابد).

The system is read-heavy — roughly 100 reads per write — so I'd cache aggressively and accept eventual consistency on the counters. If p99 spikes, we degrade gracefully: show cached counts with a "cached" badge.سیستم خوانا-محوره — تقریباً صد خواندن به هر نوشتن — پس جسورانه کش می‌کنم و سازگاریِ نهاییِ شمارنده‌ها رو می‌پذیرم. اگه p99 پرید، افتِ مؤدبانه می‌کنیم: شمارشِ کش‌شده با نشانِ «کش» رو نمایش می‌دیم.

گفتگو: پنج دقیقه از میانِ طراحیِ news feed

Interviewer: Design a news feed for 10 million users. — You: First, shape: read-heavy? The scrolling is reads; posting is writes — I'd guess 100:1. Confirmable?مصاحبه‌گر: یه فید برایِ ۱۰ میلیون کاربر طراحی کن. — تو: اول شکل: خوانا-محوره؟ اسکرول خواندنه، پست‌گذاشتن نوشتن — حدسم ۱۰۰:۱. تأیید می‌شه؟

Interviewer: Close enough — say 50:1. — You: Then the feed is a materialized list per user, updated async. The hot path is only reads from cache — Redis in front of the store.مصاحبه‌گر: نزدیک — مثلاً ۵۰:۱. — تو: پس فید یه لیستِ از پیش‌ساخته برای هر کاربره که async آپدیت می‌شه. مسیرِ داغ فقط خواندن از کشه — ردیس جلوی ذخیره.

You: The interesting trade-off is fan-out: push on write is fast to read but expensive for celebrities. Hybrid: push for normal users, pull for the famous ones. — Interviewer: That's the answer I was fishing for. — You: Ha! I've been burned by a celebrity's fan-out before — never again.تو: trade-offِ جالب fan-oute: push رویِ نوشتن، سریع‌تر برایِ خواندن ولی برای سلبریتی‌ها گرونه. هیبرید: push برای کاربرهای عادی، pull برای معروف‌ها. — مصاحبه‌گر: همون جوابیه که دنبالش بودم. — تو: ها! یه بار فن‌اوتِ یه سلبریتی من رو سوخته — دیگه هرگز.

اشتباه‌های رایجِ فارسی‌زبان‌ها در همین درس

این بخش را با یک قرارداد بخوان: هر ❌ یعنی «مغزِ فارسی‌زبانت این را می‌سازد و طبیعی است»، و هر ✅ یعنی «این همان چیزی است که گیرندهٔ انگلیسی‌زبان می‌شنود». خطاها اثرِ مستقیمِ ترجمهٔ ذهنیِ فارسی به انگلیسی‌اند؛ با هر جفت بلند تکرار کن تا شکلِ درست در گوشت نشست کند.

❌ I will use from Redis for the cache.❌ فارسیِ «استفاده از Redis» حرفِ اضافهٔ از را به فعل می‌چسباند؛ use گذراست و مستقیم مفعول می‌گیرد — use from صدای ترجمهٔ نسل‌هاست. و در طراحی، Redis جلوی دیتابیس می‌نشیند: in front of، نه فقط use.

✅ I'd put Redis in front of the database for caching.✅ شکل درست را دو بار بلند بگو؛ حالا یک بار در یک جملهٔ خودت.

❌ This system can handle one million user.❌ بعد از عددِ بزرگ، اسم جمع می‌شود: a million users؛ فارسیِ «یک میلیون کاربر» بدونِ s می‌ماند و حرفِ تعریفِ a هم غالباً جا می‌افتد. مقیاسْ شمرده می‌خواهد: عدد + جمع + حرفِ تعریف.

✅ The system can handle a million users.✅ شکل درست را دو بار بلند بگو؛ حالا یک بار در یک جملهٔ خودت.

❌ If the traffic increases, we increase the servers.❌ «سرورها را بیشتر می‌کنیم» با increase تکرار می‌شود؛ مقیاس در انگلیسیِ سیستم‌ها فعلِ خودش را دارد: scale horizontally / scale up. increase the servers صدای گزارشِ فارسی است، scale زبانِ طراحی است.

✅ If traffic grows, we scale horizontally — add more nodes behind the load balancer.✅ شکل درست را دو بار بلند بگو؛ حالا یک بار در یک جملهٔ خودت.

تمرین‌های این درس — چهار قدم، بی‌عجله

طراحیِ سیستم، گفتارِ trade-off است؛ چهار تمرین را با صدای مصاحبهٔ واقعی بگو — عدد، گزینه، معاوضه — بعد باز کن.

«بستگی دارد» را با دو گزینه ببند: نسبتِ خواندن/نوشتن ۱۰۰:۱ — چه می‌کنی؟ (دو جمله)
عدد را بلند حساب کن: «۵۰ میلیون کاربر در روز، یعنی چند درخواست در ثانیه؟»
جملهٔ سازگاری را کامل کن: «برایِ دسترس‌پذیری، سازگاریِ نهاییِ شمارنده‌ها را در عوضِ آن ___ می‌کنیم.»
افتِ مؤدبانه را توضیح بده: p99 پرید — کاربر چه می‌بیند؟ (دو جمله)

پاسخ تمرین‌ها — اول خودت جواب بده، بعد باز کن

پاسخ تمرین ۱

نمونه: "It depends on the read/write ratio — at 100:1 I'd cache aggressively; if writes were heavy, I'd shard first." depends بدونِ گزینه دوری است؛ با دو گزینه، تحلیل است.

پاسخ تمرین ۲

"Fifty million a day is about 600 requests per second — call it a thousand at peak." حسابِ بلندِ عدد، تُردِ شروعِ طراحی است؛ عددِ شمرده، درِ بحث را باز می‌کند.

پاسخ تمرین ۳

"...we accept eventual consistency on the counters in exchange for availability." قالبِ ثابت: accept X in exchange for Y. معاوضهٔ فنی «در عوضِ» با in exchange for گفته می‌شود، نه با ترجمهٔ زیروروی instead of.

پاسخ تمرین ۴

نمونه: "If p99 spikes, we degrade gracefully — serve the cached page with a 'cached' badge rather than an error." افتِ مؤدبانه یعنی بخشی می‌میرد، کل نمی‌میرد؛ همین جمله، بلوغِ طراحی را نشان می‌دهد.

چالشِ امروز

🎯 یک سیستمِ آشنا (فیدِ شبکهٔ اجتماعیِ محبوبت) را در سه جمله برای دوستِ غیرفنی طراحی کن: نسبتِ خواندن/نوشتن با عدد، یک trade-off با I'd — و بعد بپرس چه چیزی گیرش کرد.

نکات مکالمهٔ واقعی که کتاب‌ها کم می‌گویند

عددِ اول را خودت بگو — قبل از طراحی، اعداد را بلند حساب کن (QPS, ratio) — «صد میلیون در روز یعنی هزار در ثانیه» — عددِ شمرده، درهای مصاحبه را باز می‌کند.
It depends را با دو گزینه ببند — هر «بستگی داره» را با «گزینهٔ A برای حالتِ X، B برای Y» کامل کن — dependsِ بدونِ گزینه، دوری است نه تحلیل.
تجربهٔ سوخته را داستان کن — «I've been burned by X before» — سوختگیِ واقعی + درسش، محک‌ترین اعتبارِ طراحیِ توست.

🔑 جمع‌بندی این درس

چارچوبِ system design: نیازمندی‌ها و اعداد (سوالِ «چند؟» اول) → بلوک‌ها با جمله‌ی اتصال (the flow is…) → trade-off با «بسته به…» → رشد و خرابی (what breaks at 100x?) → جمع‌بندی. واژه‌های پولساز: hot path, read-heavy, shard, eventual consistency, single point of failure. کد نمی‌نویسی؛ «معماری حرف می‌زنی».

مصاحبهٔ فنی ۲؛ system design از «یک میلیون کاربر» به بالا