#تحلیل_و_طرز_تفکر (Engineering Mindset)
گاهی یک سؤال ساده می‌تواند کیفیت یک طراحی را مشخص کند:
«اگر این بخش سیستم فردا خراب شود، چه چیزی باید بتواند بدون آن ادامه دهد؟»
خیلی از سیستم‌ها برای حالت سالم طراحی می‌شوند.
ءDatabase در دسترس است.
ءRedis سالم است.
ءMessage Broker کار می‌کند.
ءExternal API پاسخ می‌دهد.
ءNetwork پایدار است.
همه‌چیز طبق انتظار پیش می‌رود.
اما Production دقیقاً جایی است که این فرض‌ها شروع به شکستن می‌کنند.
ءDatabase ممکن است ۳۰ ثانیه کند شود.
ءRedis ممکن است از دسترس خارج شود.
یک Message ممکن است دوبار Deliver شود.
یک External API ممکن است Timeout کند.
و Network ممکن است Packet Loss داشته باشد.
اینجاست که تفاوت بین یک سیستم معمولی و یک سیستم Resilient مشخص می‌شود.
سیستم خوب فقط نمی‌گوید:
«اگر همه‌چیز سالم باشد، چه اتفاقی می‌افتد؟»
بلکه می‌پرسد:
«اگر یکی از وابستگی‌های من خراب شود، دقیقاً چه چیزی باید همچنان کار کند؟»
مثلاً اگر Notification Service از دسترس خارج شد،
آیا ثبت سفارش هم باید Fail شود؟
اگر Analytics Service Down شد،
آیا کاربر باید نتواند وارد سیستم شود؟
اگر Recommendation Service پاسخ نداد، آیا صفحه محصول باید Error بدهد؟
پاسخ این سؤال‌ها را نمی‌توان با یک Pattern آماده داد.
باید از Business Requirement بیاید.
به همین دلیل، Resilience فقط اضافه کردن Retry و Circuit Breaker نیست.
اول باید مشخص کنی:
کدام شکست‌ها قابل تحمل‌اند و کدام‌ها نیستند.
بعد برایشان طراحی کنی.
چون در سیستم‌های واقعی، خرابی Exception نیست.
بخشی از شرایط عادی سیستم است که باید برایش طراحی شده باشی.