تصور کنید یکی از سرویس های وابسته شما (مثلا درگاه پرداخت یا سرویس احراز هویت) کند یا قطع شده. اگر بک اند شما بدون هیچ محافظتی مدام به آن درخواست بفرستد، چه اتفاقی میافتد؟
threadها پر می شوند، connection pool تمام می شود، latency کل سیستم بالا می رود و در نهایت سرویس های سالم هم از کار می افتند. به این پدیده Cascade Failure میگویند. یک مشکل کوچک که کل سیستم را با خود پایین می کشد.
راه حل کلاسیک و بسیار موثر این مشکل، الگوی Circuit Breaker است.
Citcuit Breaker دقیقا مثل فیوز برق عمل می کند:
وقتی تعداد خطاها از یک آستانه مشخص بیشتر شود، مدار باز می شود و درخواست های بعدی بلافاصله fail می شوند (بدون اینکه به سرویس معیوب برسند).
بعد از یک مدت مشخص (مثلاً ۳۰ ثانیه)، مدار به حالت نیمه باز می رود و چند درخواست آزمایشی می فرستد.
اگر آن ها موفق بودند، مدار دوباره بسته می شود و ترافیک عادی از سر گرفته می شود.
این کار دو مزیت بزرگ دارد:
از هدر رفتن منابع سیستم خودتان جلوگیری می کند.
به سرویس معیوب فرصت بازیابی می دهد، چون دیگر زیر بار درخواست های بی وقفه نیست.
در عمل، کتابخانه هایی مثل Resilience4j (جاوا)، Opossum (Node.js)، یا built-in قابلیت های برخی فریم ورک ها این الگو را پیاده سازی کرده اند. مهم این است که Circuit Breaker را فقط برای سرویس های خارجی حیاتی (مثلا دیتابیس های API و remote های third-party، میکروسرویس های حیاتی) فعال کنید و آستانه ها را بر اساس رفتار واقعی سیستم تنظیم کنید، نه اعداد دلخواه.
خیلی از تیم ها این الگو را بعدا می گذارند. اما تجربه نشان داده که وقتی اولین بار Cascade Failure رخ می دهد، هزینه رفع آن بسیار بالاتر از پیاده سازی اولیه اش است.
این یک الگوی ساده اما بسیار قدرتمند است که تفاوت بین یک سیستم مقاوم و یک سیستم شکننده را رقم می زند.