آموزش بیش از ۵۰۰ سوال و جواب مصاحبه طراحی سیستم (System Design) سال ۲۰۲۶ - آخرین آپدیت

پوشش دقیق حوزه‌های آزمون

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

• مقیاس‌پذیری و قابلیت اطمینان (۲۰٪): طراحی معماری‌های با دسترسی بالا (High Availability)، استقرار Load Balancing چند لایه، لایه‌های کش توزیع‌شده (Redis/Memcached)، استراتژی‌های Replication دیتابیس (Master-Slave, Multi-Master)، تحمل خطای خودکار و محیط‌های تاب‌آور بازیابی فاجعه.

• مبانی سیستم (۱۵٪): تحلیل Trade-offهای قضیه CAP، ارزیابی مدل‌های مختلف سازگاری (Consistency Models)، پیاده‌سازی بخش‌بندی موثر داده‌ها (Sharding, Consistent Hashing)، صف‌های پیام غیرهمزمان (Message Queues) و پروکسی‌های Forward/Reverse.

• ذخیره‌سازی و مدیریت داده‌ها (۱۲٪): طراحی دیتابیس‌های رابطه‌ای، انتخاب دیتابیس NoSQL (کلید-مقدار، سندی، ستونی، گرافی)، مفاهیم انبار داده (Data Warehousing)، زیرساخت‌های استخراج داده توزیع‌شده و خط لوله‌های تحلیل داده در مقیاس بزرگ.

• طراحی و توسعه API (۱۰٪): پیکربندی الگوهای API Gateway، تقویت امنیت API (OAuth2, JWT)، استقرار استراتژی‌های هوشمند Rate Limiting، ساخت RESTful APIهای قدرتمند و پیاده‌سازی رابط‌های GraphQL.

• رایانش ابری و استقرار (۸٪): معماری زیرساخت‌های ابری جهانی، مدیریت کانتینرهای عظیم (Docker)، ارکستراسیون سرتاسری (Kubernetes)، پیاده‌سازی الگوهای Serverless و ساخت خط لوله‌های بهینه CI/CD.

• شبکه و ارتباطات (۱۰٪): پروتکل‌های سطح پایین شبکه (TCP/UDP)، وب‌سوکت‌های با تاخیر کم، مکانیزم‌های HTTP Long Polling، مالتی‌پلکسینگ HTTP/2 و استریم‌های با کارایی بالای gRPC.

• تحلیل Trade-Off و تصمیم‌گیری (۱۵٪): انجام تحلیل‌های تحلیلی Trade-Off، ترسیم تحلیل هزینه-فایده برای زیرساخت، کمی‌سازی بدهی فنی، ارزیابی ریسک معماری و تدوین استراتژی‌های کاهش ریسک.

• الگوها و اصول طراحی سیستم (۱۰٪): تحلیل معماری میکروسرویس‌ها، بهینه‌سازی انتقال از معماری Monolithic، ساخت معماری‌های رویداد-محور (Event-Driven)، پیاده‌سازی طراحی دامنه-محور (DDD) و ساختاربندی معماری سرویس‌گرا (SOA).

درباره این دوره

پیمودن مسیر مصاحبه طراحی سیستم اغلب سخت‌ترین بخش برای دستیابی به جایگاه‌های ارشد فنی است. مصاحبه‌کنندگان صرفاً به دنبال کلمات کلیدی نیستند؛ آن‌ها می‌خواهند ببینند شما چگونه Trade-offها را تحلیل می‌کنید، داده‌ها را در مقیاس بالا مدیریت می‌کنید و موارد خاص (Edge Cases) غیرمنتظره را تحت فشار دنیای واقعی مدیریت می‌کنید. من این مخزن تست‌های تمرینی را ایجاد کردم تا به شما کمک کنم تفکر ساختاری دقیقی را که شرکت‌های برتر تکنولوژی می‌طلبند، پرورش دهید.

با ۵۵۰ سوال عمیق و اورجینال، این دوره بسیار فراتر از دانستنی‌های سطحی است. من شما را با شکست‌های معماری پیچیده، گلوگاه‌های سیستم‌های توزیع‌شده، Trade-offهای ذخیره‌سازی و تصمیمات حیاتی شبکه آشنا می‌کنم. هر سوال با یک تحلیل فنی جامع همراه است که توضیح می‌دهد چرا یک رویکرد درست موفق می‌شود و چرا طرح‌های جایگزین در محیط عملیاتی شکست می‌خورند. چه هدف شما جایگاه Staff Software Engineer باشد، چه برای پنل Technical Lead آماده شوید و چه بخواهید مهارت‌های خود را به عنوان معمار DevOps تکمیل کنید، این منبع تمرینات سختگیرانه‌ای را فراهم می‌کند که برای قبولی در اولین تلاش به آن‌ها نیاز دارید.

نمونه سوالات تمرینی

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

سوال ۱: هشینگ سازگار (Consistent Hashing) و تغییرات توپولوژی نودها

یک معمار سیستم، یک کلاستر ذخیره‌سازی توزیع‌شده کلید-مقدار را با افزودن چهار نود فیزیکی جدید به یک حلقه هشینگ سازگار که از نودهای مجازی استفاده می‌کند، مقیاس می‌بندد. بلافاصله پس از تغییر توپولوژی، داشبورد مانیتورینگ افزایش شدید تاخیر شبکه و نرخ Cache Miss را در سراسر کلاستر نشان می‌دهد. کدام شرط علت ریشه‌ای این افت عملکرد سیستم را توضیح می‌دهد؟

• الف) الگوریتم هشینگ دچار برخورد (Collision) شدید شد زیرا فضای نام کلید به محدوده عدد صحیح ۱۶ بیتی محدود شده است.

• ب) توپولوژی حلقه به دلیل نبود یک نود هماهنگ‌کننده Master منتخب، دچار وضعیت موقت Split-Brain شد.

• ج) حجم عظیمی از کلیدهای موجود کاملاً غیرقابل نگاشت شدند و سیستم را مجبور به اسکن کامل جدول دیتابیس برای تمام درخواست‌های خواندن کردند.

• د) اسکریپت‌های مهاجرت داده‌ها باعث باز-بخش‌بندی (Re-sharding) فوری و همزمان تمام پارتیشن‌های داده در سراسر شبکه شدند.

• ه) توزیع مجدد ناگهانی بخش‌های داده، نقاط داغ (Hot Spots) موقت و سربار جابجایی داده را هنگام تخصیص مجدد کلیدها به موقعیت‌های مجازی جدید ایجاد کرد.

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

پاسخ صحیح و توضیح:

• پاسخ صحیح: ه

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

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: پلتفرم‌های هشینگ سازگار از فضاهای رمزنگاری بزرگ (مانند MD5 یا SHA-256) استفاده می‌کنند که محدوده‌ای ۱۲۸ یا ۲۵۶ بیتی تولید می‌کنند و احتمال برخورد در فضای نام را از نظر آماری ناچیز می‌کند.

  • گزینه ب نادرست است: حلقه‌های هشینگ سازگار ساختارهای غیرمتمرکز هستند که برای مسیریابی داده‌ها بدون اتکا به یک نود Master مرکزی طراحی شده‌اند.

  • گزینه ج نادرست است: مزیت اصلی هشینگ سازگار این است که از غیرقابل نگاشت شدن کلیدها جلوگیری می‌کند؛ تنها درصد کوچک و قابل پیش‌بینی از کلیدها هنگام تغییر نودها تغییر مالکیت می‌دهند.

  • گزینه د نادرست است: هشینگ سازگار صراحتاً از Re-sharding جهانی و همزمان در سطح کلاستر اجتناب می‌کند و تنها داده‌های محلی همسایگان مستقیم نودهای جدید را جابجا می‌کند.

  • گزینه و نادرست است: اگر پروکسی‌ها تمام ترافیک را به یک نود می‌فرستادند، آن نود کاملاً کرش می‌کرد یا Time-out می‌داد، به جای اینکه باعث افزایش توزیع‌شده Cache Miss در کل کلاستر شود.

سوال ۲: گزینه‌های سازگاری داده‌های توزیع‌شده در معماری‌های چند منطقه‌ای (Multi-Region)

یک اپلیکیشن سازمانی، پیکربندی دیتابیس رابطه‌ای چند منطقه‌ای Active-Active را در دو مرکز داده دور از هم مستقر کرده است. برای تضمین Linearizability سخت‌گیرانه در تراکنش‌های مالی، مهندس سیستم یک پروتکل Commit دو مرحله‌ای همزمان (Synchronous Two-Phase Commit) را اعمال می‌کند. در هنگام وقوع یک اتفاق Partition شبکه بین مناطق، طبق قضیه CAP، تاثیر فوری بر سیستم چیست؟

• الف) سیستم تمام تضمین‌های سازگاری را رها می‌کند اما در دسترس بودن (Availability) برای نوشتن را در هر دو منطقه ایزوله حفظ می‌کند.

• ب) عملیات نوشتن در هر دو منطقه متوقف یا کاملاً رد می‌شود تا صحت داده‌ها حفظ شده و از به‌روزرسانی‌های متناقض جلوگیری شود.

• ج) دیتابیس به طور خودکار به یک Document Store تبدیل می‌شود تا بعداً تغییرات همزمان متناقض را به صورت ایمن ادغام کند.

• د) لایه مسیریابی شبکه به طور خودکار تمام ترافیک تراکنشی را از طریق یک کانال Broadcast UDP با تاخیر کم بازگردانی می‌کند.

• ه) مراکز داده به پردازش نوشتن‌ها به صورت مستقل ادامه می‌دهند و از استراتژی Last-Write-Wins برای حل تفاوت‌ها استفاده می‌کنند.

• و) موتور ذخیره‌سازی برای افزایش سرعت پردازش تا زمان بهبود Partition شبکه، Log پیش‌نویس (Write-ahead log) را دور می‌زند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحیح بودن: قضیه CAP حکم می‌کند که در هنگام Partition شبکه (P)، یک سیستم توزیع‌شده باید بین در دسترس بودن (A) و سازگاری (C) یکی را انتخاب کند. با انتخاب Linearizability سخت‌گیرانه از طریق Commit دو مرحله‌ای همزمان، معماری اولویت را به سازگاری می‌دهد. اگر یک Partition شبکه مناطق را جدا کند، آن‌ها نمی‌توانند به اجماع (Consensus) برسند و سیستم مجبور است عملیات نوشتن را رد یا متوقف کند تا از وضعیت‌های داده Split-Brain جلوگیری کند.

• دلیل نادرست بودن سایر گزینه‌ها:

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

  • گزینه ج نادرست است: دیتابیس‌ها نمی‌توانند در میانه یک تراکنش و هنگام قطع شبکه، پارادایم‌های موتور ذخیره‌سازی یا شمای رابطه‌ای خود را به صورت پویا تغییر دهند.

  • گزینه د نادرست است: تغییر پروتکل‌های شبکه به UDP مشکل Partition فیزیکی شبکه را حل نمی‌کند و UDP فاقد تضمین‌های تحویلی مورد نیاز برای اجماع تراکنشی است.

  • گزینه ه نادرست است: استراتژی Last-Write-Wins یک مدل سازگاری نهایی (Eventual Consistency) است که در سیستم‌های High-Availability استفاده می‌شود و مستقیماً با نیاز Linearizability سخت‌گیرانه در تضاد است.

  • گزینه و نادرست است: دور زدن Write-ahead log باعث نابودی دوام (Durability) و یکپارچگی تراکنشی می‌شود و به جای اینکه تاکتیکی برای کاهش اثر Partition باشد، یک شکست بحرانی محسوب می‌شود.

سوال ۳: معناشناسی پردازش پیام و Idempotency در صف‌های با نرخ انتقال بالا

یک سیستم میکروسرویس رویداد-محور از یک صف پیام غیرهمزمان برای پردازش فاکتورهای صورت‌حساب کاربران استفاده می‌کند. بروکر پیام زیربنایی، معناشناسی تحویل At-least-once (حداقل یک بار) را تضمین می‌کند. در زمان پیک‌های بار زیاد، کاربران گزارش می‌دهند که برای خریدهای تکی، دو بار هزینه کسر شده است. تیم مهندسی Backend چگونه باید این مشکل را به طور دائمی حل کند؟

• الف) میکروسرویس‌های مصرف‌کننده را طوری پیکربندی کند که در یک حلقه تک-رشته‌ای (Single-threaded) عمل کنند تا از تداخل‌های اجرای موازی جلوگیری شود.

• ب) ساختار At-least-once بروکر را با یک ساختار Pub-Sub در حافظه جایگزین کند که تاییدیه (Acknowledgment) مصرف‌کننده را نادیده می‌گیرد.

• ج) آستانه Visibility Timeout پیام را افزایش دهد تا با حداکثر زمان انتظار ممکن در Pool اتصال دیتابیس مطابقت داشته باشد.

• د) یک کلید Deduplication منحصر به فرد برای هر تراکنش معرفی کرده و یک لایه پردازش Idempotent را در سرویس مصرف‌کننده پیاده‌سازی کند.

• ه) یک توالی ترتیب سخت‌گیرانه First-In-First-Out (FIFO) را در تمام Shardهای موضوعی داخلی بروکر پیام اعمال کند.

• و) فرمت سریال‌سازی پیام را از JSON به آرایه‌های باینری با تراکم بالا تغییر دهد تا از تاخیرهای تجزیه (Parsing) جلوگیری شود.

پاسخ صحیح و توضیح:

• پاسخ صحیح: د

• دلیل صحیح بودن: تحویل At-least-once تضمین می‌کند که پیام همیشه به مقصد می‌رسد، اما در صورت قطع ارتباطات شبکه که مانع از ارسال تاییدیه شود، ریسک تحویل‌های تکراری را به همراه دارد. برای مدیریت ایمن این موضوع، سیستم‌های مصرف‌کننده باید Idempotent (هم‌توان) باشند. پردازش تراکنش‌ها با استفاده از یک کلید Deduplication منحصر به فرد (مانند ID فاکتور یا پرداخت) تضمین می‌کند که دریافت چندین باره یک پیام، تنها منجر به یک کسر وجه واقعی شود.

• دلیل نادرست بودن سایر گزینه‌ها:

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

  • گزینه ب نادرست است: نادیده گرفتن تاییدیه مصرف‌کننده منجر به تحویل At-most-once می‌شود که باعث گم شدن پیام‌ها و عدم محاسبه فاکتورها می‌گردد.

  • گزینه ج نادرست است: افزایش Visibility Timeout تکرارهای ناشی از کندی Workerها را کاهش می‌دهد، اما نمی‌تواند جلوی تحویل‌های تکراری ناشی از قطع اتصال شبکه در مراحل تاییدیه را بگیرد.

  • گزینه ه نادرست است: ترتیب FIFO تضمین می‌کند پیام‌ها به ترتیب پردازش شوند، اما مانع از ارسال یا باز-ارسال پیام‌های یکسان و تکراری توسط بروکر نمی‌شود.

  • گزینه و نادرست است: تغییر فرمت سریال‌سازی اندازه Payload را بهینه می‌کند، اما هیچ تاثیری بر منطق Retry یا تضمین‌های تحویل بروکر شبکه ندارد.

انتظارات از دوره

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

• می‌توانید هر چند بار که بخواهید در آزمون‌ها شرکت کنید.

• این یک بانک سوالات عظیم و اورجینال است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح دقیق است.

• با اپلیکیشن Udemy کاملاً سازگار با موبایل است.

امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.