هر محصول از چندین برنامهٔ قابل‌اجرا تشکیل شده که با رشد تیم و وسعت محصول، تعدادشون کم‌کم به ده‌ها یا حتی صدها برنامه می‌رسه.
سازمان‌ها معمولاً سرویس‌ها رو بر اساس اهمیت به چند سطح تقسیم می‌کنن: tier1، tier2، … تا برای هر سطح SLA، آن‌کال، و ظرفیت منابع متفاوتی تعریف کنن.
به عنوان نمونه در مثال دیجیکالا، اپلیکیشن ثبت سفارش می‌تونه tier1 باشه چون مستقیم روی درآمد و تجربه‌ی کاربر اثر می‌ذاره، اما بخش لایو اینفلونسرها tier کم‌اولویت‌تری داره و اگر چند دقیقه هم از دسترس خارج بشه، اثرات خیلی کمتری داره.
در حالت ایده‌آل، از کار افتادن یک سرویس با اولویت پایین نباید روی سرویس‌های حیاتی اثر جدی بذاره. اما همیشه این‌طور نیست؛ گاهی ارتباط سرویس‌ها طوری چیده شده که از کار افتادن یک سرویس tier4، عملاً سرویس tier1 رو هم با خودش پایین می‌کشه.
یکی از مهم‌ترین راه‌ها برای جلوگیری از این اثر زنجیره‌ای، طراحی asynchronous بین سرویس‌هاست. یعنی برنامه‌ها به‌جای وابستگی‌های synchronous و اجرای خطی، از صف‌ها، eventها یا callbackهای غیرهمزمان استفاده کنن.
خوبه هنگام طراحی ارتباط بین سرویس‌ها به این موضوع دقت کنیم و در trade-offها گزینهٔ async رو جدی‌تر بررسی کنیم.
مورد مهم دیگه انتخاب timeout مناسب و استفاده از retry + backoff و circuit breakerهاست؛ به‌طوری که اگر یکی از وابستگی‌ها قطع شد، سرویس بتونه خودش رو سرپا نگه داره و کامل از مدار خارج نشه.
رعایت این موارد کمک می‌کنه که در زمان بحران، راحت‌تر و با ریسک کمتری تصمیم به خاموش کردن موارد کم‌اولویت‌تر بگیریم و بار رو از روی دوش کل سیستم کاهش بدیم.
این نوشته رو اول در کانال تلگرام منتشر کردم. اگر دوست دارید نوشته‌های بعدی رو زودتر بخونید، پیشنهاد می‌کنم عضو کانال بشید.