आपका टिकट बंद कर दिया गया। उपयोगकर्ता फिर भी भुगतान नहीं कर सका।

आपके बैकएंड ने 200 स्टेटस कोड लौटाया। मोबाइल ऐप ने एरर दिखाया। उपयोगकर्ता ने "Pay" पर तीन बार टैप किया। उनके खाते से तीन बार पैसे कटे। एक ऑर्डर पूरा हुआ। अब उनका बैलेंस कम हो गया है। आपके लॉग्स में शून्य विफलताएं (zero failures) दिख रही हैं।

हर इंजीनियर ने अपना काम किया। किसी ने समस्या का समाधान नहीं किया।

टीमें अक्सर खराब कोड की वजह से नहीं, बल्कि गलत काम करने की वजह से विफल होती हैं। आप एक ऐसा सिस्टम लॉन्च कर सकते हैं जो पूरी तरह से काम करता है लेकिन एक बहुत ही खराब अनुभव पैदा करता है।

जूनियर इंजीनियर टिकटों के बारे में सोचते हैं। टिकट असाइन किया गया। कोड लिखा गया। टेस्ट पास हुए। PR मर्ज किया गया। टिकट बंद किया गया।

जैसे-जैसे आप आगे बढ़ते हैं, यह मानसिकता एक बोझ बन जाती है। वह इंजीनियर जो टिकट बंद करता है, वह उपयोगी है। लेकिन वह इंजीनियर जो पूछता है कि "क्या यह वास्तव में व्यावसायिक समस्या का समाधान करता है", वह अपरिहार्य है।

एक पेमेंट फ्लो पर विचार करें। बैकएंड इंजीनियर एक एंडपॉइंट बनाता है। यह चार्ज प्रोसेस करता है और सही कोड लौटाता है। 100% टेस्ट कवरेज। टिकट बंद। मोबाइल इंजीनियर स्क्रीन बनाता है। यह एंडपॉइंट को कॉल करता है और रिस्पॉन्स दिखाता है। स्मूथ UI। टिकट बंद।

वह समस्या जिसका किसी ने स्वामित्व नहीं लिया: जब चार्ज होने के बाद लेकिन मोबाइल ऐप को कन्फर्मेशन मिलने से पहले नेटवर्क चला जाता है, तब क्या होता है?

बैकएंड सफलता (success) दिखाता है। मोबाइल ऐप विफलता (failure) दिखाता है। उपयोगकर्ता फिर से प्रयास करता है और दो बार चार्ज हो जाता है।

इसका समाधान केवल बैकएंड या मोबाइल फिक्स नहीं है। इसके लिए idempotency keys की आवश्यकता होती है। मोबाइल ऐप को हर प्रयास के लिए एक यूनिक की (unique key) जेनरेट करनी चाहिए। बैकएंड को उस की का उपयोग करना चाहिए ताकि यह सुनिश्चित हो सके कि दोबारा प्रयास करने पर कभी भी डुप्लिकेट चार्ज न हो।

यह समाधान तभी संभव है जब इंजीनियर नेटवर्क ड्रॉप के दौरान उपयोगकर्ता अनुभव (user experience) के बारे में एक-दूसरे से बात करें।

यही बात हार्डवेयर के साथ भी होती है। हार्डवेयर इंजीनियर फर्मवेयर भेजता है। मोबाइल इंजीनियर ऐप भेजता है। बैकएंड इंजीनियर API भेजता है। हर हिस्सा काम करता है। हर टेस्ट पास होता है।

लेकिन उपयोगकर्ता बटन दबाता है और लाइट 11 सेकंड बाद जलती है। लेटेंसी (latency) कंपोनेंट्स के बीच के अंतराल में होती है। किसी भी एक इंजीनियर ने एंड-टू-एंड स्पीड की जिम्मेदारी नहीं ली।

वास्तविक विश्वसनीयता एक सिस्टम प्रॉपर्टी है, न कि केवल एक कंपोनेंट प्रॉपर्टी।

इसे ठीक करने के लिए, आपको अपने काम करने के तरीके को बदलना होगा:

आपका पद (job title) आपके कौशल को दर्शाता है। यह आपकी जिम्मेदारी की सीमा तय नहीं करता है।

यदि आप एक बैकएंड इंजीनियर हैं, तो आप इस बात के लिए जिम्मेदार हैं कि उपयोगकर्ता बिना किसी बाधा के भुगतान कर सकें। यदि आप एक मोबाइल इंजीनियर हैं, तो आप उपयोगकर्ता के भरोसे के लिए जिम्मेदार हैं।

टिकट क्लोज करना तो केवल न्यूनतम स्तर है। उपयोगकर्ता के परिणाम (outcome) की पूरी जिम्मेदारी लेना ही सर्वोच्च स्तर है।

स्रोत: https://dev.to/walosha/your-ticket-was-closed-the-user-still-couldnt-pay-14di