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

🎯 سوالات مصاحبه برای Microservices

اگر برای مصاحبه‌های معماری نرم‌افزار، Senior Backend یا Solution Architect آماده می‌شوید، این‌ها از مهم‌ترین سوالاتی هستند که باید بتوانید به آن‌ها پاسخ دهید. 🚀

1️⃣ چگونه مرزهای سرویس‌ها را با استفاده از Domain-Driven Design (DDD) تعریف می‌کنید؟

2️⃣ چه معیارهایی تعیین می‌کنند که یک سرویس را جدا کنید یا آن را به‌صورت مشترک نگه دارید؟

3️⃣ چگونه یک «Distributed Monolith» را شناسایی و از آن جلوگیری می‌کنید؟

4️⃣ مزایا و معایب Orchestration و Choreography چیست؟

5️⃣ چگونه از الگوی Strangler Fig برای مهاجرت سیستم‌های Legacy استفاده می‌کنید؟

6️⃣ چه زمانی یک Shared Library بهتر از الگوی Sidecar است؟

7️⃣ چه زمانی برای ارتباطات داخلی gRPC را به REST ترجیح می‌دهید؟

8️⃣ چگونه الگوی Circuit Breaker را برای جلوگیری از Cascading Failure پیاده‌سازی می‌کنید؟

9️⃣ چگونه مشکل Thundering Herd را زمانی که یک سرویس دوباره آنلاین می‌شود مدیریت می‌کنید؟

🔟 استراتژی شما برای Retry با Exponential Backoff چیست؟

1️⃣1️⃣ چگونه هنگام تکامل Schema، سازگاری عقب‌رو (Backward Compatibility) API را حفظ می‌کنید؟

2️⃣1️⃣ چگونه Idempotency را در Message Consumerها طراحی می‌کنید؟

3️⃣1️⃣ چگونه بین Sagaهای مبتنی بر Choreography و Sagaهای مبتنی بر Orchestration انتخاب می‌کنید؟

4️⃣1️⃣ چگونه Joinهای بین سرویس‌ها را برای گزارش‌گیری‌های پیچیده مدیریت می‌کنید؟

5️⃣1️⃣ مزایا و معایب Database-per-Service در مقابل Database-Schema-per-Service چیست؟

6️⃣1️⃣ چگونه تراکنش‌های توزیع‌شده را بدون Two-Phase Commit (2PC) مدیریت می‌کنید؟

7️⃣1️⃣ چگونه مشکل Dual Write را هنگام به‌روزرسانی پایگاه داده و انتشار Eventها حل می‌کنید؟

8️⃣1️⃣ چه استراتژی‌هایی برای Eventual Consistency استفاده می‌کنید؟

9️⃣1️⃣ چگونه Distributed Tracing را بین چندین سرویس پیاده‌سازی می‌کنید؟

0️⃣2️⃣ چگونه Drift شدن Configuration را بین محیط‌های مختلف مدیریت می‌کنید؟

1️⃣2️⃣ استراتژی شما برای Dead Letter Queue (DLQ) و بازپخش پیام‌ها (Message Replay) چیست؟

2️⃣2️⃣ چگونه ارتباطات Service-to-Service را ایمن می‌کنید؟

3️⃣2️⃣ چگونه تفاوت بین تأخیر شبکه (Network Latency) و کندی خود برنامه (Application Slowness) را تشخیص می‌دهید؟

4️⃣2️⃣ چگونه یک Microservice را به‌صورت ایزوله تست می‌کنید بدون اینکه کل مجموعه سرویس‌ها را Mock کنید؟

💡 بسیاری از این سوالات مستقیماً به مفاهیمی مانند:
✅ Domain-Driven Design (DDD)
✅ Event-Driven Architecture
✅ Saga Pattern
✅ Outbox & Inbox Pattern
✅ CQRS
✅ Eventual Consistency
✅ Distributed Tracing
✅ Resiliency Patterns
✅ RabbitMQ / Kafka
✅ Kubernetes & Cloud-Native Architecture
مرتبط هستند و در مصاحبه‌های سطح Senior و Architect بسیار رایج‌اند. 🚀🔥

هشتگ‌ها:
#Microservices #SoftwareArchitecture #BackendDevelopment #EventDrivenArchitecture #TechInterview

یکی از جالب‌ترین چیزهایی که در مصاحبه‌های فنی یاد گرفتم این بود که همیشه بهترین پاسخ‌ها، درست‌ترین پاسخ‌ها نیستند.
بارها پیش آمده از یک نفر پرسیده‌ام:
«برای حل این مسئله چه راهکاری پیشنهاد می‌کنی؟»
و او شروع کرده به توضیح دادن پیشرفته‌ترین معماری‌ها، Patternها و تکنولوژی‌هایی که می‌شناسد.
همه چیز از نظر تئوری درست بوده است.
اما یک سؤال همیشه در ذهنم شکل می‌گرفت:
«برای چه؟»
برای ۱۰۰ کاربر؟
برای ۱۰ میلیون کاربر؟
برای یک تیم ۳ نفره؟
یا یک تیم ۱۰۰ نفره؟
چون در مهندسی نرم‌افزار، هیچ راهکاری در خلأ خوب یا بد نیست.همه چیز به مسئله بستگی دارد.به محدودیت‌ها.به هزینه‌ها.و به Trade-offهایی که حاضر هستیم بپذیریم.
به مرور زمان متوجه شدم چیزی که در مصاحبه‌ها بیشتر از دانش فنی توجه مرا جلب می‌کند،نوع فکر کردن افراد است.
اینکه قبل از ارائه راه‌حل، چند سؤال می‌پرسند.
چقدر برای فهمیدن مسئله زمان می‌گذارند.
و چقدر حاضرند فرضیات خودشان را به چالش بکشند.
چون در دنیای واقعی،بیشتر وقت ما صرف حل مسئله نمی‌شود.صرف فهمیدن مسئله می‌شود.
و گاهی تفاوت یک توسعه‌دهنده خوب و یک مهندس نرم‌افزار خوب،در کیفیت پاسخ‌هایشان نیست.
در کیفیت سؤال‌هایشان است.

2. Data Partitioning

منابع پیشنهادی این چالش که برای من اینها جذاب بوده و هست.

A. Pro SQL Server Internals [book]
- Chapters 16 - required

B. MySql Docs
- site

@thisisnabi_dev

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

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

#مهندس_فکر_کن
قسمت:1️⃣
🎯 سوال مصاحبه مهندسی نرم‌افزار

فرض کنید یک سرویس ASP.NET Core دارید که پیام‌ها را از Kafka دریافت می‌کند.
پیام دریافت می‌شود.Business Logic اجرا می‌شود.
داده در Database ذخیره می‌شود.
اما درست قبل از Commit Offset سرویس Crash می‌کند.
پس از Restart شدن سرویس، همان پیام دوباره پردازش می‌شود.
سؤال:
چگونه از ثبت دوباره اطلاعات جلوگیری می‌کنید؟

چرا هر تیم نرم‌افزاری باید Runbook داشته باشه؟ سلام دوستان، تو دنیای امروز که سیستم‌ها ۲۴/۷ کار می‌کنن، Runbook دیگه لوکس نیست، یه ضرورت هست.Runbook چیه؟سند زنده‌ای که دقیقاً می‌گه:وقتی مشکلی پیش اومد چیکار کنیم؟ (Step-by-step)
وابستگی‌های سیستم چیا هستن؟
چک‌لیست‌های روزانه، هفتگی و ماهانه
راه‌حل‌های رایج خطاها و Incidentها
اطلاعات تماس افراد کلیدی و Escalation Path
حتی به تیم های مرتبط میگه endpoint هامون چین و ورودی خروجی های مورد انتظارش چیه


اهمیت Runbook برای تیم‌های نرم‌افزاری:کاهش چشمگیر زمان Downtime
وقتی Incident اتفاق می‌افته، دیگه کسی سردرگم نیست که "اول کجا رو چک کنیم؟" تیم تو کمتر از ۵ دقیقه وارد Action می‌شه.
کاهش وابستگی به افراد خاص
یکی از اعضای کلیدی تیم مرخصی باشه یا شرکت رو ترک کنه، دانش از دست نمی‌ره.
Onboarding خیلی سریع‌تر
developer یا SRE جدید تو همون هفته اول می‌تونه Incidentهای سطح متوسط رو هندل کنه.
Consistency در عملیات
همه اعضای تیم به یک روش استاندارد عمل می‌کنن، نه هر کسی به سلیقه خودش.
بهبود کیفیت و آرامش خاطر
وقتی بدونید همه چیز مستند شده، خواب راحت‌تری دارید!

تجربه واقعی:تیم‌هایی که Runbook خوب دارن، MTTR (Mean Time To Recovery) شون رو تا ۵۰-۷۰٪ کاهش دادن.پیشنهاد من:
همین امروز یه Runbook اولیه برای مهم‌ترین سرویس‌هاتون بسازید. حتی اگه ناقص باشه، بهتر از هیچی هست. بعد به مرور کاملش کنید.از ابزارهایی مثل Notion، Confluence، Markdown تو GitHub یا GitLab Wiki می‌تونید استفاده کنید.شما Runbook دارید؟
تو کامنت بگید تیم‌تون چقدر به مستندات عملیاتی اهمیت می‌ده؟ #DevOps #SRE #Runbook #SiteReliability #SoftwareEngineering #تیم_فنی

چند سال پیش از یکی از مدیران فنی سؤال کردم:
«چطور می‌فهمی یک تصمیم معماری خوب بوده یا نه؟»
فکر می‌کردم قرار است درباره Performance، Scalability یا Availability صحبت کند.
اما جوابش چیز دیگری بود.
گفت:
«ببین چند ماه بعد، تغییر دادن آن تصمیم چقدر درد دارد.»
آن زمان خیلی متوجه منظورش نشدم.
اما هرچه بیشتر روی سیستم‌های واقعی کار کردم، بیشتر به عمق این جمله پی بردم.
بیشتر تصمیم‌های معماری، روزی که گرفته می‌شوند عالی به نظر می‌رسند.
مشکل زمانی شروع می‌شود که نیازمندی‌ها تغییر می‌کنند.
کسب‌وکار مسیر جدیدی می‌رود.
تیم بزرگ‌تر می‌شود.
یا حجم کاربران چند برابر می‌شود.
اینجاست که کیفیت واقعی تصمیم‌ها مشخص می‌شود.
چون بعضی تصمیم‌ها فقط برای امروز بهینه هستند.
و بعضی دیگر، تغییرات آینده را هم در نظر گرفته‌اند.
جالب است که انعطاف‌پذیری یک سیستم را معمولاً از روی چیزهایی که می‌تواند انجام دهد نمی‌سنجند.
از روی چیزهایی می‌سنجند که می‌تواند تغییر دهد.
شاید به همین دلیل باشد که مهندسی نرم‌افزار کمتر درباره پیش‌بینی آینده است.
و بیشتر درباره آماده بودن برای آینده‌ای است که نمی‌توانی پیش‌بینی‌اش کنی.
در نهایت، ارزش یک طراحی خوب فقط در این نیست که امروز جواب می‌دهد.
در این است که فردا هم بتوانی با آن زندگی کنی.

#مهندس_فکر_کن
قسمت:2️⃣

🎯 مصاحبه‌کننده:
فرض کنید یک سیستم Microservice دارید.
سرویس A یک سفارش ثبت می‌کند.
سرویس B پرداخت را انجام می‌دهد.
سرویس C موجودی انبار را کم می‌کند.
سرویس D پیامک ارسال می‌کند.
در میانه کار، پرداخت موفق انجام می‌شود اما سرویس انبار از دسترس خارج می‌شود.

سؤال:
آیا باید یک Transaction سراسری تعریف کنیم تا اگر یکی از سرویس‌ها شکست خورد، همه چیز Rollback شود؟دلیل؟

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

ChatGPT:

Broken Window Theory (نظریه پنجره شکسته)
در برنامه‌نویسی یعنی:

اگر یک مشکل کوچک، کد بد یا باگ جزئی را نادیده بگیریم، کم‌کم افراد بیشتری هم بی‌نظمی را عادی می‌بینند و کیفیت کل پروژه افت می‌کند.

مثال:

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

اگر این موارد اصلاح نشوند، برنامه‌نویس‌های بعدی هم با خیال راحت کدهای نامرتب بیشتری اضافه می‌کنند. بعد از مدتی پروژه پر از «بدهی فنی» (Technical Debt) می‌شود و نگهداری آن سخت خواهد شد.

🔹 اسم این نظریه از یک مثال شهری آمده: اگر پنجره یک ساختمان شکسته باشد و تعمیر نشود، افراد تصور می‌کنند کسی به آنجا اهمیت نمی‌دهد و خرابکاری‌های بیشتری رخ می‌دهد.

پیام اصلی برای برنامه‌نویس‌ها:

> مشکلات کوچک را زود برطرف کن؛ نگذار کد نامرتب و خراب به حالت عادی تبدیل شود.

به همین دلیل تیم‌های حرفه‌ای معمولاً:

* باگ‌های کوچک را سریع رفع می‌کنند.
* کد را مرتب و خوانا نگه می‌دارند.
* قبل از Merge شدن، Code Review انجام می‌دهند.
* تست‌ها را خراب رها نمی‌کنند.

خلاصه: یک «پنجره شکسته» در کد، اگر تعمیر نشود، می‌تواند کل پروژه را به‌تدریج به هم بریزد. 🚪🔧💻

---------------
کوتاهش اینه که باید حس مسولیت پذیری داشته باشید اگر میبینید کدی خرابه یا یه جایی درست نیست ازش رد نشید و بگید این کد رو من نزدم با لید خودتون درمیون بذارید و حلش کنید یا حداقل دلیلشو بپرسید.

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