जेव्हा प्रतिसाद अदृश्य होतो तेव्हा Stripe तुमच्या विनंतीची आठवण ठेवते

या व्हिडिओमध्ये काय समाविष्ट आहे

• आयडेम्पोटेंसी म्हणजे ऑपरेशनची पुनरावृत्ती करण्याच्या अपेक्षित परिणामाची चिंता. Stripe API v1 मध्ये दस्तऐवजीकृत सेव्ह केलेला प्रतिसाद रिप्ले करार जोडला जातो.
• समान तार्किक क्रियेची पुनरावृत्ती करण्यासाठी समान की आणि पॅरामीटर्स वापरले जातात. ऑपरेशन की वेगवेगळ्या SDK कॉल किंवा ॲप्लिकेशन रीस्टार्टमध्ये टिकवून ठेवा; खऱ्या अर्थाने नवीन क्रियेला तिची स्वतःची की आवश्यक आहे.
• एंडपॉइंट कार्यान्वित करणे सुरू झाल्यानंतर, Stripe API v1 पहिल्या विनंतीची स्थिती आणि बॉडी, 500 एरर्ससह, सेव्ह करते आणि त्या सेव्ह केलेल्या प्रतिसादाला रिट्रीजवर परत करते.
• समान की सह बदललेले पॅरामीटर्स जुळत नाहीत. प्रमाणीकरण अयशस्वी झाल्यास आणि एकाचवेळी कार्यान्वित केल्यास, त्या प्रयत्नासाठी कोणताही आयडेम्पोटेंट परिणाम सेव्ह केला जात नाही आणि पुन्हा प्रयत्न केला जाऊ शकतो.
• Stripe API v1 की कमीतकमी 24 तास ठेवते आणि त्यानंतर त्यांना हटवू शकते. अनसुलझे नेटवर्क रिट्रीज पहिल्या 24 तासांपर्यंत मर्यादित ठेवा, त्यानंतर ऑपरेशन पुन्हा करण्यापूर्वी थांबून समाधान करा.
• कनेक्टिव्हिटी पूर्ववत झाल्यानंतर कॅश केलेला 500 एरर पुन्हा चालू राहू शकतो. मूळ ऑपरेशनचे साइड इफेक्ट्स असू शकतात; त्याचे परिणाम निश्चित करण्यासाठी संबंधित ऑब्जेक्ट, डॅशबोर्ड विनंती आणि वेबहुक वापरा.
• API v2 भिन्न रिप्ले सिमेंटिक्स वापरते. ईमेल, इन्व्हेंटरी आणि प्रत्येक स्थानिक डेटाबेस ऑपरेशनसाठी की युनिव्हर्सल एक्झॅक्टली-वन्स डिलिव्हरी स्थापित करत नाही.

अनुवादित प्रतिलेख

मूळ इंग्रजी निवेदनातून अनुवादित. उपलब्ध ऑडिओ आणि मथळे YouTube द्वारे नियंत्रित आहेत.

तुमचे पेमेंट टाइमआउटमुळे रद्द झाले का?

0:00 तुम्हाला वाटते की टाइमआउट म्हणजे तुमचे पेमेंट अयशस्वी झाले. प्रत्युत्तर गायब होत असताना सर्व्हर पूर्ण करू शकते, तुमचे चेकआउट आत्मविश्वासाने काहीही न दाखवता सोडून देते. पुन्हा प्रयत्न केल्यास पुन्हा शुल्क आकारले जाऊ शकते? Stripe प्रयत्न कसा लक्षात ठेवते? तुम्ही पुन्हा प्रयत्न करणे कधी थांबवावे? आणि एक वाईट तपशील लक्षात ठेवा. स्मरण केलेला एरर नेटवर्क समस्येपेक्षा जास्त काळ टिकू शकतो.

0:17 आपण त्यावर परत येऊ. हे 'द डेली डिफ', पडद्यामागे आहे.

आयडेम्पोटेंसी की काय ओळखते?

0:21 आयडेम्पोटेंसी म्हणजे ऑपरेशनची पुनरावृत्ती केल्याने ते एकदा केल्यासारखाच परिणाम होतो. एकदा. एक आयडेम्पोटेंसी की एका तार्किक क्रियेला लेबल करते. Stripe चे API व्हर्जन एक रिट्रीजवर ते लेबल ओळखते आणि सेव्ह केलेला प्रतिसाद पुन्हा प्ले करते. कॉफी खरेदी करण्याची कल्पना करा. Stripe तुमची पेमेंट विनंती पूर्ण करते आणि प्रतिसाद परत येताना हरवतो, ग्राहक स्पिनर पाहतो. त्यांच्या बँकेला अधिक रोमांचक स्पष्टीकरण असू शकते. एक असुरक्षित 'क्रिएट' विनंती साइड इफेक्ट पुन्हा करू शकते.

समान की रिट्री सुरक्षित कशी करते?

0:45 पहिल्या प्रयत्नापूर्वी एक अद्वितीय की जोडा आणि रिट्रीजसाठी ती ठेवा. तुमचे ॲप्लिकेशन रीस्टार्ट झाल्यास, तुमच्या रेकॉर्डमध्ये ऑपरेशनसह ती की जतन करा. Stripe च्या व्हर्जन वन API साठी, एकदा एंडपॉइंट कार्यान्वित करणे सुरू झाले, पहिल्या विनंतीची स्थिती आणि बॉडी सेव्ह केली जाते. समान की आणि पॅरामीटर्स पुन्हा पाठवा, आणि Stripe सेव्ह केलेला प्रतिसाद परत करते. कॉफी तिथेच राहते तर तिची पावती पुन्हा प्रवास करते.

Stripe नेमके काय सेव्ह करते?

1:07 येथे Stripe ची खरी शब्दरचना आहे. समान की सह पुन्हा प्रयत्न केल्यास सेव्ह केलेला प्रतिसाद परत येतो, पाचशे एरर्ससह. दस्तऐवजीकरण तुमच्या आशावादीपणे नाव दिलेल्या रिट्री हेल्परपेक्षा जास्त काम करते. ग्राहक पुन्हा टॅप करतो. तुमचे ॲप ठरवते की ते प्रलंबित खरेदी पुन्हा सुरू करते की दुसरी सुरू करते. एक खऱ्या अर्थाने नवीन कॉफीला नवीन की मिळते. प्रत्येक नेटवर्क रिट्रीसाठी एक नवीन की संरक्षण निष्प्रभ करते.

1:27 समान की सह भिन्न पॅरामीटर्स जुळत नाहीत.

जेव्हा विनंती बदलते तेव्हा काय होते?

1:30 जर पॅरामीटर्स प्रमाणीकरणात अयशस्वी झाले, किंवा त्या की सह दुसरी विनंती अजूनही कार्यान्वित असेल, Stripe त्या प्रयत्नासाठी कोणताही आयडेम्पोटेंट परिणाम सेव्ह करत नाही. त्या विनंत्या पुन्हा प्रयत्न केल्या जाऊ शकतात. रेसिंग विनंतीला संघर्ष होतो. हे व्हर्जन वनचे नियम आहेत. व्हर्जन टू वेगळे वर्तन करते. एक हेडर तुमच्या सिस्टममध्ये 'एक्झॅक्टली वन्स' डिलिव्हरीचे वचन देऊ शकत नाही. ईमेल, इन्व्हेंटरी आणि तुमच्या डेटाबेसला प्रत्येकाला अपयश हाताळण्याची गरज आहे.

1:52 की ऑपरेशनला त्याच्या दस्तऐवजीकृत व्याप्तीमध्ये संरक्षण देते. Stripe व्हर्जन वन की कमीतकमी चोवीस तास ठेवते आणि त्यानंतर त्यांना हटवू शकते.

स्मरण केलेला परिणाम पुन्हा प्रयत्न करण्यासाठी किती काळ सुरक्षित आहे?

1:59 हटवलेली की नवीन विनंती कार्यान्वित करू शकते. पहिल्या दिवसात अनसुलझे रिट्रीज ठेवा. त्यापलीकडे, थांबा आणि मूळ परिणामाचे समाधान करा. सर्व्हरला श्वास घेण्यासाठी एक्सपोनेन्शियल बॅकऑफ आणि जिटर वापरा. अन्यथा रिट्रीज जळणाऱ्या कॉफी शॉपच्या बाहेर रांग लावतात. Stripe च्या लायब्ररी रिट्रीज हाताळतात, पण तुमच्या लायब्ररीचे डिफॉल्ट तपासा. तो चिकट एरर हाच अडथळा आहे.

स्मरण केलेला एरर परत का येऊ शकतो?

2:20 कनेक्टिव्हिटी पूर्ववत झाल्यानंतर कॅश केलेला पाचशेचा प्रतिसाद पुन्हा चालू राहतो. मूळ ऑपरेशनने साइड इफेक्ट्स निर्माण केले असतील. ऑब्जेक्ट्स, डॅशबोर्ड आणि वेबहुक वापरून त्याचे परिणाम निश्चित करा. नवीन की कृतीची पुनरावृत्ती करू शकते. तुम्ही मला हे बोलताना ऐकण्याऐवजी वाचायला प्राधान्य देत असाल, तर 'द डिफ' दररोज सकाळी तुमच्या इनबॉक्समध्ये विनामूल्य 'the daily diff dot dev' वर येतो, लिंक खाली आहे. दररोज सकाळी, 'the daily diff dot dev' वर विनामूल्य, खाली लिंक आहे.

मी या करारासह रिट्री बटण पाठवेन का?

2:39 निकाल, पडद्यामागे. शिप इट. मी बाउंडेड रिट्रीज आणि रिकन्सिलिएशनसह स्थिर की पाठवेन, जेणेकरून ग्राहकांना तुमच्या डिस्ट्रिब्युटेड सिस्टिम शिक्षणाचा निधी न देता कॉफी मिळेल. आणि आजचा हाच फरक. मी ॲक्स्रिसीकडून निको आहे. जबाबदारीने विलीन करा.

स्रोत

1. Idempotent requestsStripe Docs
2. Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
3. Advanced error handlingStripe Docs
4. HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor