چطوری System Design رو یاد بگیریم قسمت ۲ از ۲

قسمت اول

خب خب بریم برای برای ادامه‌ی مسیر: از طراحی روی کاغذ تا آموزش دادن به بقیه

4️⃣ شروع کن به رسم، حتی اگه روی کاغذ باشه!

یه چیزی که خیلی کمک کنندس: رسم کردن (Drawing) هستش.

ما آرتیست نیستیم. ولی وقتی فلو کار رو از

دیتایبیس → اپ های سرور → لود بالانسر ها → کلانیت

رسم میکنیم تازه دیدمون باز میشه.

وقتی رسم میکنیم:

✔️ فلو درخواست واقعی به نظر می‌رسه.

✔️ میبینیم که Bottlenecks کجاها ممکنه اتفاق بیفته.

✔️ میفهمیم که کش (Cache) رو کجا بذاریم یا کِی از صف (Queue) استفاده کنیم.

هرجا گیر میکنم فقط یه قلم و کاغذ برمیدارم و شروع میکنم به رسم تا دیدم باز تر بشه و اون افکار پراکندم مرتب بشه. پیشنهاد میکنم نوشتن با ماژیک رو شیشه رو هم امتحان کنید، خیلی جوابه :)

5️⃣ با حل کردن مسئله‌های واقعی تمرین کنید

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

این روش تمرینی میتونه کمکتون کنه:

✔️ یه سیستم واقعی انتخاب کنید: واتساپ، یوتیوب، اسنپ‌فود، اینستاگرام.

✔️ اول نیازمندی‌های عملکردی (Functional Requirements) رو بنویسید (سیستم باید چیکار کنه).

✔️ بعد نیازمندی‌های غیرعملکردی (Non-functional Requirements) رو اضافه کنید (مقیاس‌پذیری، دسترس‌پذیری، تأخیر).

✔️ یه تخمین اولیه بزنید (تعداد کاربر، QPS، حجم DB).

✔️ یه معماری سطح بالا (High-level Architecture) طراحی کنید.

🚀 حالا وقت عمیق تر شدن رسیده:

✔️ DB schema
✔️APIs
✔️ Scaling strategies
✔️ Handling failures (مدیریت خطا ها)
✔️ Edge Cases (حالت های خاص)

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

چون توی مصاحبه‌ها و کارهای واقعی، به ندرت یه جواب کامل وجود داره. مهم اینه که بتونی توجیه کنی چرا X رو به Y ترجیح دادی.

6️⃣ وقت واقعی کردن رسیده

🔴تئوری تا وقتی پیاده نشه، بی‌فایده‌ست.

بذارید از تجربه خودم بگم. تویه شرکت داشتیم رو یه سیستمی کار میکردیم که به صورت میکروسرویس پیاده شده بود با Go و برای ارتباط داخلی سرویس ها از GRPC استفاده کرده بودیم. اوایل برای سرویس آنالیتیکس از MongoDB استفاده کرده بودیم. اما با زیاد شدن حجم داده ها و کوئری ها (رکورد ها به قدری زیاد بودن که حجم دیسک دیتابیس شده بود 15 گیگ) سیستم شروع کرد به کند شدن. یه راهکار ها این بود که بیایم چنتا نود مختلف بیاریم بالا ولی پیچیدگی ایش زیاد بود، پس شروع کردیم به R&D کردن دیتابیس هایی که به نظر برای این کار مناسب بودن. بعد از تست های اولیه و گرفتن بنچمارک متوجه شدیم که clickhouse میتونه توی مورد ما این بخش از پروژه رو نجات بده. تیم بکند دور هم جمع شدیم و فقط یه ماژیک برداشتیم و ساعت ها روی شیشه سیستم دیزاین های مختلفیو رسم و بررسی کردیم و دیدمون باز شد و در نهایت طرح نهایی. حالا که همه چیز حداقل روی کاغذ اماده بود و کار میکرد باید مهاجرت رو شروع و سیستم جدید رو پیاده میکردیم. در نهایت با یه بررسی درست، بررسی سیستم دیزاین های مختلف و داشتن دید کلی و جزئی از سیستم ، به جایی رسیدیم که میلیون ها داده رو بدون مشکل آنالیز کردیم و نزدیک Real time خروجی نشون میدیم. بعد آروم آروم رفتیم جلو و چیز های دیگه هم مثل RabbitMQ اضافه کردیم. اره الان پروژه بزرگ شده ولی این پروژه ی بزرگ حاصل قدم های کوچیکی بود که برداشتیم ولی نکتش اینکه اگه میخواستیم به آخرش فکر کنیم که همچین چیز بزرگی چطوری قراره ساخته بشه هیچ وقت شروع نمیشد :)

7️⃣ شروع کنید به یاد دادن به بقیه

این آخرین مرحله هست.

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

هر بار که یه چیزی رو توضیح میدم اینو میفهمم که:

اگه بتونم خیلی ساده اون رو درس بدم، پس واقعاً خوب فهمیدمش.

درنهایت طراحی سیستم شعبده‌بازی نیست.

فقط کافیه:

✔️ از اصول اولیه شروع کنید.

✔️ به موارد استفاده‌ی دنیای واقعی فکر کنید.

✔️ یه ساختار برای خودتون بسازید.

✔️ هفته‌ای تمرین کنید.

✔️ پشت هر انتخابتون بپرسید «چرا»؟

✔️ و آروم‌آروم بهتر بشید.

حتی اگه روزی ۳۰ دقیقه هم وقت بذارید، بعد از ۳ ماه تفاوت رو می‌بینید.

حرف آخر: قضیه جواب‌ها نیست، قضیه رویکرده!

توی طراحی سیستم، اغلب احساس عدم اطمینان خواهید کرد. این طبیعیه.

چیزی که مهمه اینه که چطور به یک مسئله نزدیک می‌شید.

وقتی توضیح می‌دی مقیاس چقدره یا اگه این سرویس از کار بیفته چی می‌شه؟ اینه که شما رو به یه مهندس قوی تبدیل می‌کنه. نه تعداد دیاگرام‌هایی که حفظ کردید.

با «یک URL چطور کار می‌کنه؟» شروع کنید و به طراحی اینستاگرام ختم کنید.

تعجب خواهید کرد که قدم به قدم، چقدر پیش رفتید.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily