سیستم دیزاین – قسمت سوم – چرا باید یک چارچوب داشته باشیم؟

آیا در مصاحبه های سیستم دیزاین از ما انتطار میره که سیستمی که چند صد تا مهندس نرم افزار روش وقت گذاشتن برای ماه ها تا دیزاینش کنند و پیاده سازی کنند رو توی یک ساعت براشون دیزاین کنیم؟

جواب اینکه هیچ کس از شما همچین انتظاریو نداره، خب پس چرا مصاحبه های سیستم دیزاین اصلا وجود دارند؟

در فصل سوم کتاب System design interview آقای Alex Xu به این موضوع پرداخته شده که ما از فصل الهام گرفتیم و این مقاله رو نوشتیم.

چرا مصاحبه های سیستم دیزاین وجود دارند؟

مصاحبه های سیستم دیزاین در حقیقت شبیه سازی حل کردن یک مسئله با همکاری دو فرد (مصاحبه کننده و مصاحبه شونده) با هم هستش که بتونند به راه حل هایی برسند که مناسب هدفشون باشه. به قول کتاب System design interview از آقای Alex Xu مسئله ما open-ended هستش و بهترین جواب برای یک مسئله وجود نداره.

در حقیقت تلاشی که شما در پروسه سیستم دیزاین میکنید خیلی مهم تر از نتیجه نهایی سیستم دیزاین شده هستش. به همین خاطر در پروسه سیستم دیزاین مهارت شما در طراحی، داشتن انتخاب های مختلف در طراحی و پاسخ دادن به بازخورد های سازنده سنجیده میشه.

با در نظر گرفتن مواردی که در بالا بهش اشاره شد پس میشه فهمید که مصاحبه کننده واقعا دنبال این نیستش که شما یه سیستم رو دیزاین کنید و مثل یک لقمه آماده بهش بدید، وظیفه اصلی مصاحبه کننده اینکه میخواد مهارت های شمارو بسنجه. از همین جهت خیلی ها فکر میکنن که جلسه مصاحبه، جلسه ای هستش که بخوان مهارت های فنی مصاحبه شونده رو بسنجن ولی چیزی فراتر از این هستش. مصاحبه کننده میخواد مهارت شما در مشارکت در دیزاین، تحت فشار کار کردن، حل کردن مسائل، توانایی پرسیدن سوال خوب، over engineering نکردن و توجه به tradeoff ها رو بسنجه.

پروسه چهار مرحله ای برای یک مصاحبه سیستم دیزاین

هر مصاحبه‌ی سیستم دیزاین با بقیه فرق داره. یه مصاحبه‌ی خوب معمولا محدود به چندتا جواب خاص نیست و جواب مشخص و واحدی هم براش وجود نداره. ولی با این حال، یه‌سری مراحل و نکات مشترک هست که توی همه‌ی مصاحبه‌های سیستم دیزاین باید بهشون پرداخت.

مرحله اول – صورت مسئله رو دقیق بفهم و محدوده‌ی دیزاین رو مشخص کن (Design scope).

از بچگی، اکبر همیشه اولین کسی بوده که توی کلاس به سوالا جواب می‌داده. هر وقت معلم سوال می‌پرسید، همیشه یه بچه‌ای هست که سریع می‌پره وسط، چه جواب رو بدونه چه ندونه اون بچه همیشه اکبر بود.

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

اما… تو مثل اکبر نباش.

توی مصاحبه‌ی سیستم دیزاین، اینکه سریع و بدون فکر جواب بدی هیچ امتیازی برات نداره. اگه بدون اینکه کامل نیازمندی‌ها رو بفهمی بری سراغ جواب، یه سیگنال منفی خیلی بزرگ به مصاحبه‌گر دادی. این یه مسابقه‌ی اطلاعات عمومی نیست که یه جواب درست براش وجود داشته باشه.

پس عجله نکن برای دادن راه‌حل، با دقت فکر کن و شروع کن به سوال پرسیدن برای شفاف کردن نیازمندی‌ها و فرضیات. این یکی از مهم‌ترین بخش‌های مصاحبست.

ما برنامه نویس ها دوست داریم بپریم وسط مسئله و سریع بریم سراغ دیزاین نهایی، ولی این روش خیلی وقت‌ها باعث می‌شه سیستم اشتباهی رو طراحی کنیم. یکی از مهم‌ترین مهارت‌های یه مهندس اینه که بلد باشه سوال درست بپرسه، فرضیات درستی داشته باشه و همه‌ی اطلاعات لازم برای ساخت سیستم رو جمع کنه. پس از سوال پرسیدن نترس.

وقتی سوالی می‌پرسی، یا مصاحبه‌گر مستقیم جواب میده یا ازت می‌خواد خودت فرضیاتتو مشخص کنی. اگه مورد دوم پیش اومد، اون فرضیات رو حتماً یادداشت کن…

چه سوال‌هایی باید بپرسی؟
سوال‌هایی بپرس که کمک کنه نیازمندی‌ها رو دقیق بفهمی. اینا یه لیست از سوالاییه که می‌تونه شروع خوبی باشه:

• دقیقا چه قابلیت‌ها و فیچرهایی قراره بسازیم؟
• محصول الان چند تا کاربر داره؟
• شرکت انتظار داره چه سرعتی توی رشد داشته باشه؟ مقیاس مورد انتظار توی ۳ ماه، ۶ ماه و یک سال آینده چقدره؟
• تکنولوژی استک شرکت چیه؟ چه سرویس‌های آماده‌ای وجود داره که بشه ازشون استفاده کرد تا طراحی رو ساده‌تر کنیم؟

مثال:

فرض کن ازت خواستن یه سیستم News Feed طراحی کنی. باید سوال‌هایی بپرسی که کمکت کنه نیازمندی‌ها رو روشن کنی. گفت‌وگو بین تو و مصاحبه‌گر ممکنه این‌جوری پیش بره:

کاندید: این یه اپلیکیشن موبایله؟ یا وب؟ یا هر دو؟
مصاحبه‌گر: هر دو.
کاندید: مهم‌ترین فیچرهای این محصول چیا هستن؟
مصاحبه‌گر: اینکه کاربر بتونه پست بذاره و فید دوستاشو ببینه.
کاندید: ترتیب نمایش پست‌ها به چه صورت هست؟ به‌صورت معکوس زمان (Reverse Chronological) یا یه ترتیب خاصی دارن؟ مثلاً اینکه پست‌های دوستای نزدیک مهم‌تر باشن از پست‌های گروه‌ها.
مصاحبه‌گر: برای اینکه ساده‌تر بمونه، فرض کنیم فید به صورت معکوس زمان مرتب می‌شه.
کاندید: هر کاربر تا چند تا دوست می‌تونه داشته باشه؟
مصاحبه‌گر: ۵۰۰۰ نفر.
کاندید: حجم ترافیک چقدره؟
مصاحبه‌گر: ۱۰ میلیون کاربر فعال روزانه (DAU).
کاندید: فید فقط متنیه؟ یا شامل عکس و ویدیو هم می‌شه؟
مصاحبه‌گر: می‌تونه انواع مدیا داشته باشه، از جمله عکس و ویدیو.

این‌ها نمونه‌هایی از سوال‌هایی هستن که می‌تونی تو مصاحبه بپرسی. خیلی مهمه که بتونی نیازمندی‌ها رو بفهمی و ابهام‌ها رو برطرف کنی.

مرحله دوم – طراحی کلی (High level design) رو پیشنهاد بده و نظر مصاحله گر رو جلب کن

در این مرحله، قراره طراحی سطح بالا (High-Level Design) انجام بدیم و با مصاحبه‌گر به یه توافق مشترک برسیم. بهترین کار اینه که توی این مسیر، مصاحبه‌گر رو به عنوان هم‌تیمی در نظر بگیری و باهاش همکاری کنی.

• یه طرح اولیه برای سیستم پیشنهاد بده و ازش بازخورد بگیر. سعی کن حس همکاری ایجاد کنی، چون خیلی از مصاحبه‌گرهای خوب دوست دارن وارد بحث بشن و نظر بدن.
• شروع کن به کشیدن دیاگرام جعبه‌ای (Box Diagram) از اجزای اصلی روی وایت‌برد یا کاغذ؛ مثلا کلاینت‌ها (موبایل/وب)، APIها، سرورهای وب، دیتابیس، کش، CDN، صف پیام و غیره.
• Back-of-the-envelope estimation انجام بده تا مطمئن شی طرحی که ارائه دادی مقیاس‌پذیره. حتما بلند بلند فکر کن و اگر لازمه از خود مصاحبه‌گر بپرس که آیا این محاسبات سرانگشتی ارزش انجام دادن دارن یا نه.

اگه فرصت شد، چند تا سناریوی واقعی رو هم بررسی کن، این کار کمک می‌کنه تصویر واضح‌تری از طراحی سطح بالا داشته باشی. تازه ممکنه با همین سناریوها به یه سری موارد خاص (edge cases) هم برسی که قبلاً بهشون فکر نکرده بودی.

یه سؤال هم اینجا مطرح میشه: آیا تو این مرحله باید API endpointها و اسکیمای دیتابیس رو هم طراحی کنیم؟
جوابش بستگی به مسئله داره. اگه مثلاً سوال “طراحی موتور جست‌وجوی گوگل” باشه، این سطح از جزئیات زیادی Low level هستش. ولی اگه سوال “طراحی بک‌اند برای یه بازی چندنفره پوکر” باشه، کاملاً منطقیه.
در کل بازم با مصاحبه‌گرت صحبت کن و ازش راهنمایی بگیر.

مثال
بیاین با مسئله‌ی «طراحی سیستم News Feed» نحوه‌ی نزدیک شدن به High level design رو بررسی کنیم. اینجا لازم نیست دقیق بدونی که این سیستم چطوری کار می‌کنه

تو High level design، ماجرا رو می‌شه به دو مسیر اصلی تقسیم کرد:
۱. انتشار پست (Feed Publishing)
۲. ساخت News Feed برای کاربر (News Feed Building)

• انتشار پست: وقتی یه کاربر پستی منتشر می‌کنه، اطلاعات مربوط به اون پست توی دیتابیس یا کش ذخیره می‌شه و بعد این پست توی News Feed دوست‌های اون کاربر هم ظاهر می‌شه.
• ساخت News Feed: توی این مرحله، سیستم میاد پست‌های دوستان کاربر رو جمع می‌کنه و به صورت برعکسِ زمان انتشار (از جدید به قدیم) می‌چینه و نمایش می‌ده.

توی دیاگرام پایین میتونیم High level design این مسئله رو نگاه کنیم. دو دیاگرام مجزا برای دو سناریو متفاوت طراحی شده که میتونید مشاهده بکنید. (اگه درک دیاگرام هایی که در این مقاله استفاده شده براتون سخت بود نگران نباشید چون توی مقاله های بعد با جزئیات توضیح میدم)

سناریو اول:

و سناریو دوم:

مرحله‌ی سوم – شیرجه‌زدن در عمق طراحی (Design Deep Dive)

در این مرحله، تو و مصاحبه‌گرت باید به این موارد رسیده باشید:

• روی اهداف کلی سیستم و فیچرها به توافق رسیده‌اید
• یه طرح کلی از معماری High level رو با هم ترسیم کردید
• از مصاحبه‌گر در مورد همین طرح بازخورد گرفته‌اید
• یه‌سری ایده‌ی اولیه برای بخش‌هایی که قراره عمیق‌تر بررسی بشن، بر اساس بازخوردش پیدا کردید

حالا وقتشه که با همکاری مصاحبه‌گر، اجزای معماری رو شناسایی و بر اساس اهمیتشون اولویت‌بندی کنید.

نکته‌ای که باید بهش توجه کنی اینه که هیچ دو مصاحبه‌ای شبیه هم نیستن. گاهی ممکنه مصاحبه‌گر تمایل داشته باشه بیشتر روی طراحی سطح بالا تمرکز کنه. ولی برای یه پوزیشن senior ممکنه بحث بره سمت ویژگی‌های عملکردی سیستم، مثل شناسایی bottleneck یا تخمین منابع. توی خیلی از مصاحبه‌ها، مصاحبه‌گر می‌خواد ببینه چقدر خوب می‌تونی بری داخل جزئیات یه کامپوننت خاص.

مثلاً اگه سیستم URL Shortener داری طراحی می‌کنی، طراحی تابع هش که قراره URL بلند رو به یه آدرس کوتاه تبدیل کنه می‌تونه موضوع جالبی برای عمیق شدن باشه. یا توی یه سیستم چت، بحث‌هایی مثل کاهش latency یا مدیریت وضعیت آنلاین/آفلاین می‌تونن جذاب باشن.

یه نکته‌ی حیاتی: مدیریت زمان خیلی مهمه. خیلی راحت ممکنه درگیر جزئیاتی بشی که نه فقط کمکی به ارزیابی تواناییت نمی‌کنن، بلکه وقت باارزشت رو هم می‌گیرن. مثلاً اینکه بخوای الگوریتم EdgeRank فیسبوک برای رتبه‌بندی پست‌ها رو به جزئیات توضیح بدی، توی مصاحبه طراحی سیستم حرکت اشتباهی محسوب میشه. چون نه فقط طولانیه، بلکه تأثیری هم در نشون دادن توانایی طراحی سیستم مقیاس‌پذیر نداره.

مثال:

تا اینجا، طراحی سطح بالای یک سیستم News Feed رو بررسی کردیم و مصاحبه‌گر هم با طرح پیشنهادی تو موافقه. حالا وقتشه بریم سراغ بررسی دقیق‌تر دو تا از مهم‌ترین سناریوهای استفاده:

۱. منتشر کردن پست (Feed Publishing)
۲. دریافت News Feed کاربران (News Feed Retrieval)

در دیاگرام های پایین دو سناریو که بالاتر در بخش High level design بهش پرداختیم با جزئیات بیشتری طراحی شدند رو میتونید مشاهده بکنید.

دیزاین با جزئیات سناریو اول:

و دیزاین با جزئیات سناریو دوم:

مرحله چهارم – جمع‌بندی نهایی

در این مرحله‌ی پایانی، ممکنه مصاحبه‌گر چند تا سؤال تکمیلی ازت بپرسه یا اجازه بده خودت موضوعات دیگه‌ای رو مطرح کنی. اینجا چند مسیر خوب برای ادامه‌ی گفت‌و‌گو هست:

• ممکنه ازت بخواد گلوگاه‌های سیستم رو شناسایی کنی و پیشنهاد‌هایی برای بهبودش بدی. یادت باشه هیچ‌وقت نگیا طراحی من بی‌نقصه و نیازی به بهبود نداره، همیشه جا برای بهتر شدن هست. این نقطه‌ی طلاییه که تفکر انتقادی و دید مهندسیت رو نشون بدی و تاثیر نهایی مثبتی بذاری.
• می‌تونی یه مرور کلی روی طراحیت داشته باشی، مخصوصا اگه چند راه‌حل مختلف پیشنهاد داده باشی. این کار کمک می‌کنه حافظه‌ی مصاحبه‌گر رو تازه کنی، مخصوصا بعد از یه جلسه‌ی طولانی.
• صحبت کردن درباره‌ی سناریوهای خطا (مثل قطعی سرور یا از بین رفتن ارتباط شبکه) می‌تونه نشون بده چقدر طراحیت واقع‌گرایانست و فقط برای حالت ایده‌آل ساخته نشده.
• مسائل عملیاتی مثل مانیتورینگ، ثبت خطاها و …
• یکی دیگه از موضوعات جذاب، آمادگی برای scale سیستم در مقیاس بزرگ‌تره. مثلاً اگه طراحی فعلیت برای ۱ میلیون کاربر جواب میده، باید بتونی توضیح بدی که اگه قرار باشه ۱۰ میلیون کاربر داشته باشی، چه تغییراتی لازمه.
• در نهایت، اگه وقت بیشتری داشتی، چه کارهایی رو بهتر یا دقیق‌تر انجام می‌دادی؟ گفتن این موارد نشون می‌ده که علاوه بر طراحی خوب، ذهنی باز و توسعه‌پذیر داری.

برای جمع‌بندی، بیایم یه مرور سریع داشته باشیم روی کارهایی که باید انجام بدی و اون‌هایی که باید ازشون پرهیز کنی:

کارهایی که باید انجام بدی (Dos):

• حتماً سؤال بپرس و ابهامات رو روشن کن؛ هیچ‌وقت فرض نکن چیزی که تو ذهنت هست قطعاً درسته.
• نیازمندی‌های مسئله رو کامل بفهم. بدون اینکه واقعاً بدونی چی قراره طراحی کنی، نمی‌تونی طراحی درستی ارائه بدی.
• یاد بگیر که جواب درست یا جواب بهترین وجود نداره. راه‌حلی که برای یه استارتاپ کوچیک جواب می‌ده، با راه‌حل یک شرکت با میلیون‌ها کاربر فرق داره. پس حتماً متناسب با شرایط، طراحی کن.
• افکارت رو با صدای بلند به اشتراک بذار. بذار مصاحبه‌گر بدونه داری به چی فکر می‌کنی.
• اگه امکانش بود، چند رویکرد مختلف پیشنهاد بده. این نشون می‌ده که دید باز و ذهن تحلیلی داری.
• بعد از اینکه طرح کلی رو با مصاحبه‌گر نهایی کردید، برو سراغ طراحی جزئیات. اول از بخش‌های بحرانی‌تر شروع کن.
• ایده‌هات رو با مصاحبه‌گر چک کن. یه مصاحبه‌گر خوب خودش نقش هم‌تیمی رو بازی می‌کنه.
• هیچ‌وقت جا نزن. حتی اگه یه بخشی رو بلد نبودی، مسیر فکریت رو ادامه بده و نشون بده چطور جلو می‌ری.

کارهایی که نباید انجام بدی (Don’ts):

• بدون آمادگی وارد مصاحبه نشو. سؤالات رایج طراحی سیستم رو حتماً تمرین کن.
• بدون روشن شدن نیازمندی‌ها و فرضیات، مستقیم نرو سراغ راه‌حل.
• از همون اول وارد جزئیات یه کامپوننت خاص نشو. اول یه تصویر کلی بده، بعد اگه لازم بود وارد جزئیات شو.
• اگه گیر کردی، از کمک گرفتن نترس. پرسیدن سؤال هوشمندانه نشونه‌ی ضعف نیست.
• در سکوت فکر نکن. مصاحبه‌گر باید بفهمه داری چطور فکر می‌کنی.
• فکر نکن طراحی‌ات رو گفتی و مصاحبه تموم شده. پایان طراحی، شروع صحبت درباره‌ی بهبودها، مقیاس‌پذیری و بحث‌های جدی‌تره.

یه مصاحبه طراحی سیستم خوب، بیشتر از اینکه درباره‌ی جواب نهایی باشه، درباره‌ی شیوه‌ی فکر کردن و نحوه‌ی برخورد حرفه‌ای با مسئله‌ست.

تخصیص زمان در هر مرحله

سؤالات طراحی سیستم معمولاً گسترده و باز هستند، و واقعاً توی ۴۵ دقیقه یا یک ساعت نمی‌شه کل سیستم رو کامل طراحی کرد. برای همین مدیریت زمان توی این مصاحبه‌ها یه مهارت حیاتی به حساب میاد.

حالا چقدر زمان باید به هر بخش اختصاص بدی؟ جدول زیر یه تخمین تقریبی برای یه جلسه ۴۵ دقیقه‌ایه. البته این فقط یه راهنماست؛ زمان واقعی به پیچیدگی مسئله و سبک مصاحبه‌گر بستگی داره.

مرحله اول – صورت مسئله رو دقیق بفهم و محدوده‌ی طراحی رو مشخص کن — حدود ۳ تا ۱۰ دقیقه

هدف این بخش مشخص کردن نیازمندی‌ها، محدودیت‌ها و ابعاد کلی سیستمه. این مرحله پایه‌ی ادامه‌ی طراحی‌ته.

مرحله دوم – طراحی کلی (High level) رو پیشنهاد بده و نظر مصاحله گر رو جلب کن — حدود ۱۰ تا ۱۵ دقیقه

در این مرحله یه نمای کلی از سیستم می‌کشی (با دیاگرام یا توضیح شفاهی) و با مصاحبه‌گر در موردش هم‌فکری می‌کنی. تأیید اون به معنی مجوز ورود به جزئیاته.

مرحله‌ی سوم – شیرجه‌زدن در عمق طراحی (Design Deep Dive) — حدود ۱۰ تا ۲۵ دقیقه

روی بخش‌های مهم‌تر سیستم تمرکز می‌کنی، مثل دیتابیس، کش، queue، load balancer یا هر بخشی که سیستم حول اون می‌چرخه. سعی کن از مصاحبه‌گر هم راهنمایی بگیری که کدوم بخش براش جالبه.

مرحله چهارم – جمع‌بندی نهایی — حدود ۳ تا ۵ دقیقه

یه خلاصه‌ی حرفه‌ای بده از کل چیزهایی که طراحی کردی. اگه وقت بیشتری داشتی، بگو چطور می‌تونستی طراحی رو بهتر کنی یا به چه چالش‌هایی فکر کرده بودی.