विफलता को सँभाल सकने वाले माइक्रोसर्विसेज़

माइक्रोसर्विसेज़ का चित्र बनाना आसान है, उन्हें चलाना कठिन। असली काम तब शुरू होता है जब कोई dependency धीमी हो, कोई संदेश दो बार पहुँचे या deployment के बाद API के दो संस्करण एक साथ चल रहे हों।

विफलता को ध्यान में रखकर डिज़ाइन करें #

दूर की सेवा को की गई call कभी स्थानीय function call के बराबर नहीं होती। हर request की deadline तय करें, केवल सुरक्षित रूप से दोहराए जा सकने वाले operations को retry करें और jitter के साथ exponential backoff इस्तेमाल करें। बिना बजट का retry एक अस्वस्थ सेवा की समस्या को पूरे सिस्टम की घटना में बदल सकता है।

Event processing को आइडेमपोटेंट बनाएँ #

Event-driven प्रणालियों को duplicate delivery मानकर चलना चाहिए। स्थिर event identifier जोड़ें और processed identifiers को business transaction के साथ रखें। तब consumers दोबारा वही प्रभाव पैदा किए बिना दोहराए गए संदेशों को स्वीकार कर सकते हैं।

दिखने और मापने वाली सीमाएँ चुनें #

Structured logs, correlation IDs, latency histograms और queue-depth metrics सेवा की सीमाओं पर हो रहा व्यवहार स्पष्ट करते हैं। Observability लॉन्च के बाद जोड़ी गई सजावट नहीं है; वह इंटरफ़ेस का हिस्सा है।

उद्देश्य हर विफलता रोकना नहीं है। उद्देश्य विफलताओं को सीमित, समझने योग्य और उनसे उबरने योग्य रखना है।