👨‍💻تاحالا فکر کردید چطور می‌شه توی یه پروژه از چندتا زبان برنامه‌نویسی مختلف کنار هم استفاده کرد؟ مثلاً یه تیکه کد به زبان C داشته باشیم که یه تابع از زبان Rust رو صدا بزنه؟ داشتم یه ویدیو تو یوتیوب می‌دیدم که دقیقاً همین موضوع رو با جزئیات خیلی خوبی توضیح می‌ده. اگه فکر می‌کنید کامپایلرها صرفا کد شما رو مستقیم به فایل اجرایی تبدیل می‌کنن، این ویدیو حسابی غافلگیرتون می‌کنه!

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

ویدیو توضیح می‌ده که فرآیند کامپایل یه مسیر چند مرحله‌ایه، نه یه تبدیل آنی. مثلاً برای زبان C با کامپایلر GCC این مراحل رو داریم:

⬅️ 1. پیش‌پردازش (Pre-processing): کدهای اضافی مثل کامنت‌ها حذف و ماکروها با کد اصلی جایگزین می‌شن.

⬅️ 2. کامپایل (Compilation): کد آماده‌شده به زبان اسمبلی (Assembly) ترجمه می‌شه که یه نسخه قابل فهم‌تر برای انسانه .

⬅️ 3. اسمبلی (Assembly): کد اسمبلی به زبان ماشین (کد باینری) تبدیل و یه فایل آبجکت (object file) ساخته می‌شه .

⬅️ 4. لینک (Linking): اینجاست که جادو اتفاق می‌افته! لینکر میاد فایل‌های آبجکت مختلف (که می‌تونن از زبان‌های مختلف باشن) و کتابخونه‌ها رو به هم می‌چسبونه و فایل اجرایی نهایی رو تحویل می‌ده.

این جدا بودن مراحل به ما اجازه می‌ده که زبان‌های مختلف رو با هم ترکیب کنیم. چون در نهایت، چیزی که برای لینکر مهمه، فایل‌های آبجکت هستن، نه اینکه این فایل‌ها از چه زبانی اومدن. مثلاً GCC فقط یه کامپایلر C نیست، بلکه یه «مجموعه کامپایلر گنو» هست که به خاطر همین معماری ماژولار، از کلی زبان مختلف پشتیبانی می‌کنه.

اما چطور این زبان‌ها با هم حرف می‌زنن؟ اینجا یه مفهوم کلیدی به اسم ABI (Application Binary Interface) وارد می‌شه . ABI مثل یه قرارداد بین‌المللی برای کدهای باینریه. این قرارداد مشخص می‌کنه که توابع چطور باید داده‌ها رو به هم پاس بدن و خروجی رو برگردونن تا همه چیز درست کار کنه . زبان‌های مدرن ابزارهایی مثل extern در C و Rust یا bind در FORTRAN رو فراهم کردن تا مطمئن بشن کدی که تولید می‌کنن، از این قراردادها پیروی می‌کنه.

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

📹 https://www.youtube.com/watch?v=XJC5WB2Bwrc

---

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

🆔 @MdDaily

داشتم یه پست از Nimrod Kramer میخوندم، می‌گفت:


کافیه دیگه. مهندسی پرامپت، مهندسی نیست. (Prompt engineering is not engineering)

چسبوندن کلمه‌ی «مهندسی» به «نوشتن پرامپت»، مثل اینه که به مهندسی اجتماعی بگیم یک شاخه از مهندسی نرم‌افزار. مسخره است، ولی به طرز عجیبی برای معتبر نشون دادنِ کار، جواب می‌ده.

بیاین روراست باشیم... نوشتن یه پرامپت خوب برای هوش مصنوعی می‌تونه هوشمندانه، نکته‌سنجانه و حتی هنرمندانه باشه. اما این مهندسی نیست. نه طراحی سیستمی در کاره، نه ریاضیاتی، نه تکرارپذیری و نه منطقِ قابل آزمایش. فقط آزمون و خطاست و (گاهی وقتا) حس و حال.

این کار بیشتر به وِرد خوندن شبیهه تا توسعه نرم‌افزار.

«مهندسی» خطاب کردنش، یکی از بزرگترین دروغ‌های تبلیغاتیه از وقتی که پای هوش مصنوعی به زندگی ما باز شد. این عنوان، یه کار ساده مثل تبلیغ‌نویسی رو به یه شغل با حقوق‌های نجومی تبدیل کرد. باعث شد آدما فکر کنن دارن سیستم می‌سازن، در حالی که فقط داشتن با مدل‌های زبان بزرگ (LLMها) وَر می‌رفتن.

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

بیاید به کلمات احترام بذاریم. هر چیزی که بوی تکنولوژی می‌ده، لازم نیست لباس مهندسی تنش کنه.


---

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

🆔 @MdDaily

اگه دنبال مجموعه ابزارهایی هستید که موقع توسعه کارتون رو سریع تر کنن، پس حتما dev tools رو امتحان کنید :)

مجموعه از ابزار های مختلفیو مثل :

- JSON Viewer

- QR Code Generator

- Markdown

- CRON Calculator

- Color Palette Generator

و .... رو با تمرکز روی privacy در اختیارتون میذاره.

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

🌐 https://dev-tool.dev/


🌐 https://gchq.github.io/CyberChef/


---

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

🆔 @MdDaily

پاول دورف به مناسبت 2️⃣1️⃣ سالگی تلگرام توی کانالش نقل قول هایی جالبی از پدرش گفته :

👨‍🏫 یک ماه پیش، پدرم — که از برجسته‌ترین متخصصان ادبیات روم باستان است — ۸۰ ساله شد. از او پرسیدم چه توصیه‌ای را باید به نسل بعد منتقل کنم. او سه نکته به من گفت:

👨‍💻 ۱. با عمل رهبری کنید. مردم — به‌ویژه کودکان — آنچه انجام می‌دهید را دنبال می‌کنند، نه آنچه می‌گویید. تماشای تلاش خستگی‌ناپذیر پدرم در نگارش کتاب‌ها و مقالات علمی فراوان، به من و برادرم معنای فداکاری را نشان داد و ما را به سخت‌کوشی نیز برانگیخت.

💖 ۲. روی جنبه مثبت تمرکز کنید. پدرم که در لنینگرادِ پس از جنگ بزرگ شد، آموخت احساساتش را کنترل کند تا نیرویی مثبت برای خانواده، همکاران و جامعه باشد. او به من آموخت افکارم را طوری شکل دهم که بیشترین خیر را حتی در روزهای سخت به همراه داشته باشد.

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

برای مورد سومی که پاول بهش اشاره کرده جا داره اضافه کنم که بعضی از چیزا ذاتش به خودیه خود قشنگه و اون باید هدف باشه نه وسیله ای برای رسیدن به یه چیز دیگه. مثلا صادق بودن به خودیه خود چیز قشنگیه نه چون صادق باشیم چون میخوایم به یه هدفی برسیم.

یا مثلا خوشحال کردن یه نفر دیگه به خودیه خود کار قشنگیه نه اینکه کسیو خوشحال کنیم و منتظر جبرانش باشیم :)

با بی دریغ انجام دادن دنیا رو به جای بهتری تبدیل کنیم ❤️


---

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

🆔 @MdDaily

👩‍💻 نسخه‌ی جدید فلاتر، یعنی Flutter 3.35، منتشر شده و کلی قابلیت هیجان‌انگیز با خودش آورده که تمرکزشون بیشتر روی بالا بردن سرعت و کیفیت کدنویسیه. بیاید چندتا از باحال‌ترین‌هاش رو با هم ببینیم.

🔥 هات ری‌لود پایدار برای وب

اولین خبر مهم برای اوناییه که با فلاتر برای وب کد می‌زنن: Stateful Hot Reload برای وب بالاخره پایدار شد! دیگه لازم نیست برای دیدن هر تغییر کوچیکی کل صفحه رو رفرش کنید. از این به بعد، مثل اپ‌های موبایل، تغییرات رو به صورت لحظه‌ای و با حفظ state برنامه می‌بینید. این یعنی یه جهش بزرگ توی سرعت توسعه‌ی وب با فلاتر!

🖼 پیش‌نمایش زنده ویجت‌ها (Widget Previews)

قابلیت شگفت‌انگیز این نسخه، معرفی Widget Previews به صورت آزمایشیه! اگه با ابزارهایی مثل Storybook توی دنیای وب کار کرده باشید، دقیقاً می‌دونید این چیه. این قابلیت بهتون اجازه می‌ده ویجت‌هاتون رو به صورت کاملاً ایزوله و جدا از کل اپلیکیشن ببینید، تست کنید و توسعه بدید. می‌تونید یه ویجت رو همزمان توی سایزهای مختلف صفحه، با تم‌های روشن و تاریک و فونت‌های متفاوت کنار هم ببینید. برای ساختن دیزاین سیستم یا تست کردن کامپوننت‌ها فوق‌العاده‌ست!

⚙️ بهبودهای موتور رندرینگ Impeller

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

⬅️ کاهش زمان استارت اپ: برنامه‌ها سریع‌تر از قبل بالا میان.

⬅️ بهینه‌سازی رندر کردن مسیرها (Path rendering): انیمیشن‌ها و UIهای پیچیده عملکرد بهتری دارن.

⬅️ افزایش کیفیت بصری: افکت‌هایی مثل blur حالا تمیزتر و باکیفیت‌تر نمایش داده می‌شن.

👁 توجه ویژه به دسترسی‌پذیری (Accessibility)

فلاتر همیشه به فراگیر بودن اپ‌ها اهمیت می‌ده. تو این نسخه ویجت جدیدی به اسم SemanticsLabelBuilder معرفی شده. کارش اینه که بهتون کمک می‌کنه چندتا داده‌ی مختلف رو با هم ترکیب کنید و به صورت یک پیام منسجم و قابل فهم برای ابزارهای صفحه‌خوان (Screen Readers) ارائه بدید. اینجوری کاربرهایی که از این ابزارها استفاده می‌کنن، تجربه‌ی خیلی بهتری از اپ شما خواهند داشت.

🤖 هوشمندتر شدن با کمک هوش مصنوعی

با معرفی Dart and Flutter MCP Server، حالا دستیارهای هوش مصنوعی (AI Coding Assistants) می‌تونن به عمق پروژه‌تون دسترسی داشته باشن. هوش مصنوعی می‌تونه خطاهای (runtime) رو خودش پیدا و رفع کنه، بهترین پکیج رو از pub.dev پیدا و نصب کنه.


چندتا اتفاق مهم دیگه هم افتاده:

⬅️سریع‌تر شدن Analysis Server: ابزارهایی مثل dart analyze و dart fix تقریباً ۵۰٪ سریع‌تر شدن که باعث می‌شه تجربه‌ی کدنویسی روزمره‌تون خیلی روون‌تر بشه.

⬅️جداسازی کتابخونه‌های Material و Cupertino: تیم فلاتر تصمیم گرفته این دوتا کتابخونه‌ی طراحی رو از هسته‌ی اصلی جدا کنه. این کار باعث می‌شه آپدیت‌هاشون سریع‌تر و مستقل از نسخه‌های فلاتر منتشر بشه و جامعه‌ی برنامه‌نویس‌ها راحت‌تر بتونن تو توسعه‌شون مشارکت کنن.

⬅️ ویجت‌های جدید و بهبودیافته: کلی ویجت جدید مثل DropdownMenuFormField و CupertinoExpansionTile اضافه شده.


همه ی این ها بخشی از مقاله ای هست که تیم فلاتر منتشر کرده. برای دیدن جزئیات کامل تغییرات پیشنهاد میکنم مقاله ی تیم فلاتر رو بخونید:

📱 https://medium.com/flutter/whats-new-in-flutter-3-35-c58ef72e3766

---

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

🆔 @MdDaily

📄 فهرست مدارک و گواهینامه‌های رایگانی که تو دنیای کار اعتبار دارن:

احتمالا اسم freecodecamp رو زیاد شنیده باشید و اولین مورد لیستم هست :

1. https://freecodecamp.org/learn/

2. دوره های دانشگاه هلسینکی:

👩‍💻 Python Programming
https://programming-25.mooc.fi

📊 Data Analysis with Python
https://courses.mooc.fi/org/uh-cs/courses/data-analysis-with-python-2024-2025

🤖 AI
https://elementsofai.com

👩‍💻 DevOps with Kubernetes
https://devopswithkubernetes.com

👩‍💻 Fullstack Web Development
http://fullstackopen.com

همه ی دوره هاش: https://mooc.fi/en/courses/

3. سیسکو نت‌اکد (Cisco Netacad)

👩‍💻 Python
http://netacad.com/courses/python-essentials-1

👩‍💻 JavaScript
http://netacad.com/courses/javanoscript-essentials-1

📊 Data Analytics
http://netacad.com/courses/data-analytics-essentials

😒 Ethical Hacking
http://netacad.com/courses/ethical-hacker

🌐 Networking
http://netacad.com/courses/networking-basics

4. گواهینامه‌های اوراکل (Oracle Certifications)

☁️ Cloud
📊 Data
🤖 AI

🔗 https://education.oracle.com/race-to-certification-2025

5. آکادمی سیلور (Saylor Academy)

👩‍💻👩‍💻 Database
👩‍💻 OS
🖥 Networking
📊 Data Science

🔗 https://learn.saylor.org/course/index.php?categoryid=9

6. دانشگاه هاروارد

🧑‍💻 Computer Science
https://cs50.harvard.edu/x/2025/

👩‍💻 Python
https://cs50.harvard.edu/python/2022/

🤖 AI
https://cs50.harvard.edu/ai/2024/

👩‍💻 Web Dev
https://cs50.harvard.edu/web/2020/

7. آکادمی هاب‌اسپات (HubSpot Academy)

می‌تونید گواهینامه‌های مربوط به سئو (SEO)، بازاریابی، فروش و کلی چیزای دیگه رو بگذرونید

🔗 https://academy.hubspot.com/certification-overview

8. Neo4j

❯ Neo4j Certified Professional
https://graphacademy.neo4j.com/certifications/neo4j-certification/

❯ Neo4j Graph Data Science Certification
https://graphacademy.neo4j.com/courses/gds-certification/

9. Hackerrank


Get certified and also earn badges for free on Hackerrank.

👩‍💻👩‍💻 SQL
👩‍💻 👩‍💻👩‍💻👩‍💻 Python, Java, JavaScript, Golang
👩‍💻👩‍💻 React, Angular
❯ DSA

🔗 https://hackerrank.com/skills-verification


10. Kaggle

👩‍💻 Python
👩‍💻👩‍💻 SQL
🤖 AI/ML, DL
📊 Data Science

🔗 https://kaggle.com/learn

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

---

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

🆔 @MdDaily

برای حل چالش بالا بردن سرعت برنامه و کاهش فشار روی منابع یکی از مکانیزم های کشینگ مورد علاقم که بسته به use case زیاد ازش استفاد میکنم LRU Cache هست.

کلمه LRU مخفف عبارت "Least Recently Used" هست. این مکانیزم به زبان ساده، داده‌هایی رو که اخیراً بیشتر استفاده شدن، نگه می‌داره و اگه حافظه پر بشه، هوشمندانه قدیمی‌ترین داده‌ای رو که بهش دست نزدیم، حذف می‌کنه تا جا برای داده‌های جدید باز بشه.

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

-----

الگوریتم پیاده‌سازی

برای فهمیدن LRU Cache و اینکه چرا انقدر کارآمد هست، باید بدونید که این سیستم از ترکیب دو تا ساختار داده اصلی ساخته شده:

⬅️ یک نقشه (Hash Map): این بخش برای جستجوی سریع داده‌ها با کلیدشون استفاده می‌شه. با این کار، پیدا کردن یک داده در کش در زمان ثابت O(1) اتفاق می‌افته و دیگه نیازی به گشتن توی کل داده‌ها نیست.

⬅️ یک لیست پیوندی دوطرفه (Doubly Linked List): این لیست وظیفه داره ترتیب استفاده از داده‌ها رو نگه داره. جدیدترین داده همیشه در ابتدای (Head) لیست قرار می‌گیره و قدیمی‌ترین داده هم در انتهای (Tail) اون. با این ساختار، می‌تونیم با سرعت بالا داده‌ها رو جابه‌جا کنیم یا قدیمی‌ها رو حذف کنیم.

حالا چطور کار می‌کنه؟

وقتی یه داده رو از کش دریافت (Get) می‌کنید، سیستم اول تو نقشه دنبال کلیدش می‌گرده. اگه پیداش کرد، اون داده رو از هر جایی که تو لیست پیوندی هست، جدا می‌کنه و به ابتدای لیست می‌بره تا "تازگی" اون به‌روز بشه.

وقتی هم یه داده جدید اضافه (Put) می‌کنید، سیستم بررسی می‌کنه که آیا اون داده از قبل وجود داشته یا نه. اگه قبلاً بود، فقط مقدارش رو آپدیت می‌کنه و می‌ذاره اول لیست. اگه جدید بود و کش هم پر بود، قدیمی‌ترین داده رو از انتهای لیست حذف می‌کنه و بعد داده جدید رو به اول لیست اضافه می‌کنه.

این ترکیب هوشمندانه از هش‌مپ و لیست پیوندی باعث می‌شه که هر دو عملیات اصلی کشینگ با بالاترین سرعت ممکن انجام بشن و برای همین هم LRU Cache یک تکنیک فوق‌العاده برای بهینه‌سازی پرفورمنسه.


یه نمونه ساده هم با Go پیاده کردم که توی این gist میتونید ببینید:

https://gist.github.com/mdpe-ir/bb25dac1ed506bd529292f0f52ecc929

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


منابع بیشتر

این مقاله هم منبع خوبی برای درک عمیق‌تر الگوریتم‌ها و نحوه پیاده‌سازی اونه:

🌐 Interview Cake: LRU Cache



---

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

🆔 @MdDaily

امروز ۲۵۶اُمین روز سال میلادی، یعنی روز برنامه‌نویسه!

این روز رو به همه کسایی که با هر خط کد، یه ایده رو به واقعیت تبدیل می‌کنن و ساعت‌ها برای بهینه‌تر شدن یه الگوریتم وقت می‌ذارن، تبریک می‌گم. برنامه نویسی از نظر من یعنی هنر ساختن و حل مسئله.

---

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

🆔 @MdDaily

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

داشتم یه مقاله از 📱 میخوندم با عنوان چطوری System Design رو یاد گرفتم. اول بریم سراغ این مقاله و آخر کارم منابعی که قبلا توی کانال معرفی کردم رو بهشون لینک میدم.

نویسنده ی مقاله که سفر یادگیریش رو باهامون به اشتراک میذاره میگه زمانی بود که هر ویدیو یا بلاگی که اسم «طراحی سیستم» (System Design) روش بود رو کلاً بی‌خیال می‌شده و با خودش میگفته اینا مال سنیور هاست نه من. بعد میره تو مصاحبه بهش میگن برای طراحی یه اپ مثل Uber باید چیکار کرد.

اصلاً نمی‌دونسته چطور باید از پس مقیاس‌پذیری بربیاد، هیچ ایده‌ای راجع به صف‌ها (Queues) نداشته، یا حتی نمی‌دونست چطور موقعیت لحظه‌ای کاربرها رو ذخیره کنه.

اینجاس که System Design وارد میشه.

---

1️⃣ اول از همه حالا که میدونیم چیو نمیدونیم بریم یادش بگیریم

طراحی سیستم اولش خیلی ترسناکه.

آدما یه سری کلمه میگن مثل «شاردینگ» (Sharding)، «CQRS»، «متوازن‌کننده بار» (Load Balancer)، (Eventual Consistency) و...

همه اولش احساس گم شدن دارن.

طراحی سیستم یه موضوع تکی نیست. یه «فصل» نیست که بتونی تو یه هفته تمومش کنی.

بلکه ترکیبی از ایناست:

✔️ جریان حرکت داده‌ها چطوریه؟

✔️ سرویس‌ها چطور با هم صحبت می‌کنن؟

✔️ چطور سیستم‌ها زیر بار ترافیک سنگین دوام میارن؟

✔️ و چطور می‌شه سیستم رو قابل‌اطمینان، سریع و مقاوم در برابر خطا (Fault-tolerant) ساخت؟

پس دست از تلاش برای کمال‌گرایی باید برداشت و روی موفقیت‌های کوچیک تمرکز کرد.

---

2️⃣ «طراحی سیستم» رو به موضوعات کوچیک تقسیم کنیم

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

بریم برای نقشه راه:

الف) اصول اولیه (The Basics)

✔️ وقتی توی مرورگر یه آدرس (URL) رو تایپ می‌کنی، چه اتفاقی می‌افته؟

✔️ مفاهیم DNS، متوازن‌کننده بار (Load Balancer) و CDN چی هستن؟

✔️ پروتکل TCP در برابر UDP، HTTP در برابر HTTPS

ب) داده و ذخیره‌سازی (Data and Storage)

✔️ دیتابیس SQL در برابر NoSQL

✔️ ایندکسینگ (Indexing)، رپلیکا (Replication)، شاردینگ (Sharding)

✔️ کی باید MongoDB رو انتخاب کنی و کی PostgreSQL؟

ج) تکنیک‌های مقیاس‌گذاری (Scaling Techniques)

✔️ مقیاس‌گذاری افقی (Horizontal) در برابر عمودی (Vertical)

✔️ کشینگ (Caching) (مثل Redis، Memcached)

✔️ متوازن‌سازی بار (Load Balancing) (مثل Round-robin، IP Hashing)

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

د) الگوهای معماری (Architecture Patterns)

✔️ مونولیت (Monolith) در برابر میکروسرویس‌ها (Microservices)

✔️ معماری مبتنی بر رویداد (Event-Driven Architecture)

✔️ مفاهیم Pub/Sub، صف‌های پیام (Message Queues) (مثل Kafka، RabbitMQ)

---

3️⃣ تماشای تفکر آدم‌های واقعی، نه فقط آموزش دادن اون‌ها

به جای دیدن ویدیوهایی که سبک آموزشی دارن، شروع کنید به دیدن مصاحبه‌های شبیه‌سازی‌شده (Mock Interviews).

و باور کنید، این کل قضیه رو عوض میکنه.

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

کانال‌هایی که خیلی کمک کننده میتونن باشن:

🎞 یوتیوب Gaurav Sen: توضیح دادن از صفر و اساس

🎞 یوتیوب Exponent: مصاحبه‌های شبیه‌سازی‌شده با کاندیداهای واقعی

🎞 یوتیوب ByteByteGo: رویکرد بصری و قصه‌گویی‌شون

بهتون یاد میده چطور:

✔️ سؤالات درست و شفاف‌کننده بپرسید.

✔️ نیازمندی‌های عملکردی (Functional) و غیرعملکردی (Non-functional) رو تعریف کنید.

✔️ مراحل طراحی API، انتخاب پایگاه داده و منطق مقیاس‌گذاری رو توضیح بدید.

✔️ و همیشه در مورد مبادله‌ها (Tradeoffs) صحبت کنید، نه فقط انتخاب‌ها.

—-

⬅️ هنوز تموم نشده و ادامه در قسمت بعدی

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

🆔 @MdDaily

چطوری 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

میخواستم بک گراندم رو عوض کنم و دنبال یه جایی بودم که کلی بک گراند خوب و رایگان داشته باشه، پس توی ریپو های گیت هاب سرچ کردم و رسیدم به پروژه lwalpapers . حدودا ۳ سالی هست که اپدیت نشده ولی ۱۰۰۰ تا بک گراند یونیک رو توی خودش جمع آوری کرده.

آدرس وبسایت:

🔗 https://wallpaper.castorisdead.xyz/

—-

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

🆔 @MdDaily

داشتم یه مقاله فوق‌العاده از یه تجربه عملیاتی سنگین می‌خوندم با عنوان: «چطور یک میلیارد رکورد رو از DB1 به DB2 جابجا کردیم؛ بدون Downtime» 🚀

نویسنده مقاله (و تیمش) با یه چالش بزرگ روبرو بودن: دیتابیس قدیمیشون که دیتای حساس مالی (پرداخت، سفارش و...) رو نگه می‌داشت، از ۱ میلیارد رکورد رد شده بود و به شدت کند شده بود, Queryهایی که ثانیه‌ای طول می‌کشید، `Batch Job`ها (کارهایی که دسته‌ای مثل تسویه حساب‌ها) ساعتی طول می‌کشید. Scale کردن (افزایش مقیاس) دیگه جواب نمی‌داد و باید مهاجرت می‌کردن، اونم بدون حتی یک ثانیه Downtime (قطعی).

این خلاصه‌ی قدم‌به‌قدم کاریه که انجام دادن:

1️⃣ جابجایی دیتای قدیمی (Bulk Migration)

برای انتقال Cold data (دیتای قدیمی که دیگه تغییر نمی‌کنه)، نیومدن یه Dump (فایل خروجی) گنده بگیرن. به جاش:

✔️ جدول رو بر اساس رنج Primary Key (کلید اصلی جدول) به Chunk (تکه‌های کوچیک دیتا) تقسیم کردن.

✔️ موقع بارگذاری، ایندکس‌های ثانویه و `Constraint`ها (قیدها) رو غیرفعال کردن (تا سرعت Insert (ثبت دیتا) بالا بره).

✔️ چندتا ورکر رو Parallel (موازی) برای انتقال این تیکه‌ها ران کردن.

✔️ بعد از انتقال هر تیکه، یه Checksum (یه جور کد محاسباتی برای چک کردن یکی بودن دیتا) می‌گرفتن تا مطمئن بشن دیتا دقیقاً کپی شده.

2️⃣ مدیریت ترافیک زنده (Dual Writes)

چالش اصلی، دیتای جدیدی بود که همزمان با مهاجرت داشت وارد می‌شد.

✔️ اپلیکیشن رو طوری تغییر دادن که Dual Writes (نوشتن همزمان در دو دیتابیس) انجام بده (یعنی هر دیتای جدید رو همزمان هم تو دیتابیس قدیمی و هم تو دیتابیس جدید بنویسه).

✔️ برای اینکه مطمئن بشن دیتایی گم نمی‌شه، اگه نوشتن تو دیتابیس جدیده خراب می‌شد، اون رویداد (event) رو می‌نداختن توی یه `Retry Queue` کافکا (صفی برای کارهای شکست‌خورده که باید دوباره امتحان بشن).

✔️ یه Consumer (سرویسی که از صف کافکا دیتا می‌خونه) جدا اون صف رو می‌خوند و اونقدر تلاش می‌کرد تا بالاخره تو دیتابیس جدیده هم ثبت بشه.

✔️ برای جلوگیری از تکراری ثبت شدن دیتا (موقع تلاش مجدد)، همه‌ی نوشتن‌ها رو با آیدی یکتا Idempotent (یعنی اگه یه کاری رو چند بار هم اجرا کنی، نتیجه نهایی یکی باشه) کرده بودن.

3️⃣ تست پنهانی در پروداکشن (Shadow Reads)

خب، دیتاها سینک بودن. ولی آیا دیتابیس جدیده زیر بار واقعی جواب می‌داد؟

✔️ اینجا از Shadow Reads (خوندن پنهانی از دیتابیس جدید برای تست) استفاده کردن.

✔️ مشتری‌ها هنوز داشتن از دیتابیس قدیمی می‌خوندن اما در پشت صحنه، اپلیکیشن همون `Query` رو روی دیتابیس جدیده هم می‌زد و نتایج رو با هم مقایسه می‌کرد.

✔️ این کار باعث شد کلی باگ ریز ولی حیاتی رو پیدا کنن که تو تست‌ها معلوم نمی‌شد: مثلاً تفاوت رفتار Timezone ها (منطقه‌های زمانی)، تبدیل `NULL`ها (مقادیر پوچ) به مقادیر پیش‌فرض، و تفاوت در Collation (قواعد مرتب‌سازی و مقایسه متن‌ها) (که باعث می‌شد مرتب‌سازی نتایج فرق کنه).

4️⃣ لحظه جابجایی نهایی (The Cutover)

روز Cutover (لحظه جابجایی کامل و سوییچ کردن)، ریسک اصلی این بود که Cache (حافظه موقت) دیتابیس جدیده «سرد» (Cold) بود و اولین کوئری‌ها ممکن بود خیلی کند باشن.

✔️ قبل از سوییچ، با اجرای کوئری‌های مصنوعی، کش دیتابیس جدید رو Pre-warm (گرم کردن کش با دیتای الکی) کردن.

✔️ ساعت ۴:۳۰ صبح (کمترین ترافیک) با زدن یه Feature Flag (یه جور کلید نرم‌افزاری برای روشن/خاموش کردن قابلیت‌ها)، همه‌ی Read ها (خوندن‌ها) رو به سمت دیتابیس جدید فرستادن. (برای اطمینان، Dual Writes رو هنوز روشن نگه داشتن تا راه برگشت امن داشته باشن).

5️⃣ رصد کردن (Observability) 📊

نویسنده میگه چیزی که واقعاً نجاتشون داد، SQL خفن نبود، بلکه Observability (قابلیت رصد کامل سیستم) بود. اونا وسواسی همه‌چیز رو مانیتور می‌کردن:

✔️ با Replication Lag (میزان عقب بودن دیتابیس‌های کپی از دیتابیس اصلی)

✔️ با `Deadlock`ها (وقتی دوتا پروسه قفل منتظر هم می‌مونن)

✔️ با Cache Hit Ratio (درصدی از دیتا که از کش خونده می‌شه نه از دیسک)

✔️ با شمارنده‌ی عدم تطابق نتایج در Shadow Reads

✔️ و از همه مهم‌تر: `KPI`های بیزینسی (شاخص‌های کلیدی عملکرد مثل سفارش در دقیقه).

ما چی می تونیم یاد بگیریم؟ 💡

مهاجرت‌های بزرگ، یه «مسئله دیتابیسی» نیستن، بلکه یه «مسئله System Design (طراحی سیستم)» هستن.

شما یه میلیارد ردیف رو یهو جابجا نمی‌کنید، بلکه batch امن به batch امن»، «ورودی WAL (فایلی که دیتابیس قبل از هر کاری، تغییرات رو اول اونجا می‌نویسه) به WAL» و «Checksum به Checksum» این کار رو می‌کنید.

در نهایت: Zero Downtime (قطعی صفر) شانسی نیست؛ طراحیه.

—-

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

🆔 @MdDaily

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

یا مثلاً تو یه بازی کامپیوتری، اون هوش مصنوعی (AI) دشمن چطوری انقدر قشنگ شما رو پیدا می‌کنه و کوتاه‌ترین راه رو برای رسیدن بهتون انتخاب می‌کنه؟

اینا همشون دارن یه مسئله‌ی معروف به اسم «پیدا کردن کوتاه‌ترین مسیر» (Shortest Path) رو حل می‌کنن. تو این پست میخوایم بریم سراغ دوتا از غول‌های حل این مسئله: دایکسترا (Dijkstra) و اِی-اِستار (A*).

1️⃣ الگوریتم دایکسترا (Dijkstra): کاوشگرِ وظیفه‌شناس (ولی کور!)

این الگوریتم که اسمش رو از خالقش، ادسخر دایکسترا، گرفته، کوتاه‌ترین مسیر از مبدأ رو پیدا میکنه.

چطوری کار می‌کنه؟

✔️ از نقطه‌ی شروع (Source) کارش رو شروع می‌کنه.

✔️ یه «صف اولویت» (Priority Queue) داره. کارش اینه که در هر مرحله، گرهی (node) رو برای بررسی انتخاب می‌کنه که کمترین هزینه (cost) رو از مبدأ داشته باشه.

✔️ این الگوریتم «کور» (Uninformed) ـه. یعنی چی؟ یعنی اصلاً نمی‌دونه مقصد کجاست! 😅

✔️ در نتیجه، جستجوش به صورت «یکنواخت» (مثل Uniform Cost Search) پخش می‌شه. کارش اینه که به صورت سیستماتیک کوتاه‌ترین مسیر از مبدأ به همه‌ی نقاط دیگه رو حساب کنه تا اینکه بالاخره اتفاقی به مقصد ما هم برسه.

نتیجه این روش چیه؟

مزیت: اینه که تضمین می‌کنه کوتاه‌ترین و بهینه‌ترین مسیر رو پیدا می‌کنه (بهش میگن Optimal)، البته به شرطی که وزن منفی (negative weight) تو گراف نداشته باشیم (مثلاً راهی که به جای هزینه داشتن، بهت زمان اضافه کنه!).

عیب: چون «کوره» و نمی‌دونه هدف کجاست، کلی زمان و انرژی صرف بررسی گره‌هایی می‌کنه که اصلاً در جهت مقصد نیستن. (مثلاً می‌خوای از تهران بری شمال، این بنده خدا همزمان مسیرهای به سمت اصفهان رو هم چک می‌کنه، چون شاید یه راه عجیبی از اونجا باشه!).

2️⃣ الگوریتم A* (A-Star): کاوشگرِ هوشمند (و هدفمند)

اِی-اِستار (A*) نسخه‌ی باهوش‌تر و «زرنگ»ترِ دایکستراست. می‌تونیم بگیم A* همون دایکسترای خودمونه، فقط یه «قطب‌نما» یا «GPS» هم دستش گرفته.

چطوری کار می‌کنه؟

✔️ اِی-استار هم مثل دایکسترا، هزینه‌ای که واقعاً تا الان طی کرده (یعنی مسافت واقعی از مبدأ تا گره فعلی) رو حساب می‌کنه. (ریاضیش رو بخوامی بگیم g(n)).

✔️ اما، برگ برنده‌اش اینجاست: اون یه «حدس هوشمندانه» (Heuristic) هم می‌زنه که چقدر فکر می‌کنه تا مقصد مونده. (ریاضیش رو بخوامی بگیم h(n)).

هیوریستیک یعنی چی؟

خیلی ساده‌ست: در مسیریابی، بهترین هیوریستیک همون «فاصله خط صاف» خودمونه. یعنی تو نقشه یه خط صاف از جایی که هستی تا مقصد بکشی.

✔️ پس اِی-استار در هر قدم، میره سراغ گرهی که مجموعِ «هزینه واقعی تا اینجا» + «هزینه تخمینی تا مقصد» (f(n) = g(n) + h(n)) از همه کمتر باشه.

نتیجه این هوشمندی چیه؟

مزیت: چون «آگاه» (Informed) هست و یه «حس جهت‌یابی» داره، جستجوی خودش رو مستقیم می‌بره به سمت هدف. دیگه الکی همه‌جا رو نمی‌گرده و در نتیجه خیلی خیلی سریع‌تره و گره‌های (nodes) کمتری رو بررسی می‌کنه.

عیب (یا نکته مهم): همه‌چی به «خوب» بودن اون حدس (Heuristic) بستگی داره. اگه هیوریستیک شما «قابل قبول» (Admissible) نباشه (یعنی بدبین باشه و فاصله رو بیشتر از حد واقعی حدس بزنه)، A* ممکنه گول بخوره و اصلاً جواب بهینه (Optimal) رو پیدا نکنه!


💡 خب، ما چی یاد گرفتیم؟ (Dijkstra vs A*)

دایکسترا: «کور»ـه و جستجوش (UCS) در تمام جهات پخشه. هدفش پیدا کردن کوتاه‌ترین راه از مبدأ به همه‌ی نقاطه.

اِی-اِستار: «هوشمند»ـه و با کمک هیوریستیک به سمت هدف می‌گرده. هدفش پیدا کردن کوتاه‌ترین راه از مبدأ به یک مقصد مشخصه.

حالا یه نکته:

الگوریتم دایکسترا در واقع یه حالت خاص از الگوریتم A* هست!

چطوری؟ اگه توی A*، اون «حدس هوشمندانه» (h(n)) رو برای همه‌ی گره‌ها صفر در نظر بگیری (یعنی عملاً بگی: «آقا من هیچ حدسی ندارم!»)، الگوریتم A* دقیقاً تبدیل می‌شه به دایکسترا!

پس کی از کدوم استفاده کنیم؟

برو سراغ Dijkstra:

* وقتی می‌خوای کوتاه‌ترین مسیر از یک نقطه به تمام نقاط دیگه رو بدونی (مثلاً تو پروتکل‌های روتینگ شبکه مثل OSPF که باید بدونن بهترین راه تا همه‌ی روترهای دیگه چیه).

برو سراغ A*:

* وقتی یک مبدأ و یک مقصد مشخص داری (۹۹٪ کاربردهای ما مثل GPS، مسیریابی تو بازی‌ها، رباتیک و...).

* وقتی سرعت برات مهمه و می‌تونی یه هیوریستیک خوب (مثل فاصله خط صاف) حساب کنی.

دفعه‌ی بعدی که «نشان» رو باز کردید یا تو یه بازی مثل The Last of Us دیدید که دشمن چقدر هوشمندانه دنبالتون میاد، یادتون باشه که یه چیزی شبیه A* پشت صحنه داره کار می‌کنه.

—-

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

🆔 @MdDaily