Episode 21: Idempotent APIs | System Design Fundamentals | Punjabi

Systemic Stack विच्ट तो अड़ा स्वागत है, मेरा नाम तुशार शर्मा है, एस System Engineering सीरीज दा इकीमा एपिसोड है, अते आज जैसी, आइडम पोटिंट APIs बारे इस तरीके नल गल करांगे, जो तो हनु इस विशेते System Engineering इंटरव्यूआ ले तयार होन विच मदद करेगा, देखो, Network फि अते देखांगे कि के में युनीक आइडम पोटेंसी की स्टर डे स्टेट नूं कंसिस्टेंट रख दिया हन पामें क्लाइंट्स दुबारा री ट्राई क्यों ना करन। किसे भी हाई स्टेक्स आर्किटेक्चर ले एक बहुत ही जरूरी कॉंसेप्ट है। असी सब तो पहला अ फिर असी सही तरीके नाल डिफाइन करांगे कि आईटम पोटेंसी असल विच की है, अते एक किवे यकीनी बढ़ाऊं दी है कि एक को रिक्वेस्ट नू कई वार भेजन दा नतीजा बिलकुल ओही निकले जो एक वार भेजनते निकल दा है। इस तो बाद असी HTTP मेथड्स दिय जथे असी चार स्टेप वाले चेक प्रोसेस स्टोर लॉजिक नू समझांगे अते रेडिस वरगे टूल्स दी वर्तो करके रिक्वेस्ट्स नू ट्रैक करनली स्टोरेज स्ट्राटीजीज बारे गल करांगे असी की एक स्पाइरी अते क्लीनप बारे वी चर्चा करांगे क्यो अखीर विच असी इंटर्व्यू दे निजरिये तो कुछ खास गलना सांजिया करांगे के प्रेशर दे दोरान इना डिजाइन चोईसेज नू किवे समझाणा है। इस सेशन दे खतम होन तक तुसी अज़े हे APIs बनाने सिख जाओगे जो network fail होनते वी बिल्कुल सही कम करंगे। हो सकदा है कि क्लाइंट दा टाइम आउट हो जावे जा सर्वर पेमिंट ता प्रोसेस कर देवे पर उस दी कनफरमेशन रस्ते विच किते गवाज जावे ए बिल्कुल उही स्थितिया जित्थे चीजां खतरनाक हो जान दियाने जे कर क्लाइंट नूँ कनफरमेशन नहीं मिली असी अजे हे सिस्टमा दी गल कर रहे हैं, जित्थे state consistency ही एक अजे ही चीज है, जो एक वधिया user experience अते एक पूरी तरह वित्ती जाटा दी तबाही दे विचकार खड़ी हुन दिये। ए तो अड़ी design चोना विच defensive होन बारे है। आओ network विच होन वाली इस गड़बडी बारे ग उन्हानों कुछ पता नी हुन्दा, इसलिए उन्हानों मजबूरन रीट्राई करना पहनदा है। एडेमपोटेंसी तो बिना इम मामूली जही लगण वाली रीट्राई डेटा खराब होंदा एक वड़ा खत्रा बन जान्दी है। जे तुसी कोई inventory system बना रे हो, ता एक गवा� प्रोसेसिंग, ग्वाची होई एक, अते री ट्राई, ए दिखाऊंदा है कि तुसी डिस्ट्रिब्यूटेड सिस्टमा दी इस बुन्याद दी अनिश्चित्ता नो चंगी तरह समझ देऊं। ए सिर्फ कोई टेक्निकल एजुकेस नहीं है, एहू असलियत है जिसनों त्यानवि ता फेर इस दा असली हल की है ओ है आईडेम पोटेंसी असल विच एक जही खुबी है जिते किसे ओपरेशन नू कई वार चलाया जा सकता है पर पहली वार सफल होन तो बाद अंतिम नतीजे विच कोई बदलाव नहीं होंदा एई यो चीज है जो क्लाइंट ले ही री ट्राइ क पर जे मैं कहां light नूँ toggle करो, अते मैं ये 10 वार कहां, ता अंतिम नतीजा पूरी तरह इस गलते निर्भर करेगा कि ओ कमांड किन्नी वार मिली सी, API डिजाइन वेच असी चोहने आ कि वद तो वद ओपरेशना नूँ उस पहली safe category विच ले अनदा जावे, जदो तुसी ये गर जे ऐसी फॉर्मल तरीके नाल गल करिए, ताइक आइडेमपोटेंट एपी आई ये पक्का कर दिये के इकको रिक्वेस्ट नू वार वार पे जनते, सिस्टम ते पैणवाडा असर बिलकुल ओही होवेगा, जो पहली वार पे जनते होया सी। इस पिछे मैथ बहुत सिंपल है, हुण असल दुनिया विच इस दा मतलब ए नहीं है कि सर्वर हर वार बिल्कुल एकको जेहा HTTP रिस्पॉंस वापस करेगा हो सक्दा है कि पहली वार तो हन्नू 201 created मिले अते दूजी वार 200 OK पर सिस्टम दी अंदरून्नी स्टेट स्थिर रहन दी है ये थे सब तो जरूरी गाल ए है कि एक क्लाइंट दे retry logic नूँ duplicate resource बढन दे खतरे तो वक कर दिन दा है जे तुसी इसनू लागू नहीं कर दे तो इस दा मतलब है कि तुसी अपने database दी सुरख्या नूँ public internet ते पर उसे चाड़ रहे हो जो कि किसे वड़ी मुसीबत नूँ सद आते बिजनेस दोवाल एक वटी मुसीबत बन जानदा है. रीट्राई सेफटी एक जेही सहूलत है, जो क्लाइंट्स मों अपने कनेक्शन दियां दिक्कतानू हल करन ले, खुल के कोशिश करन दी अजाज़त दिन दी है, उहो भी इस डर तो बिना कि किते कस्टमर नू दो वार इसनों नजर अंदाज करन दा नतीजा काफी पारी हो सकता है, तो अडियां माइक्रो सर्विसेज दे विचकार डेटा दा तालमेल विगड जावेगा, जिस करके बाद विच्थवानों हत्थी डेटा क्लीनप करना पवेगा, अते यूजर्स भी गुस्चिन होनगे। अपनी � हो नाओ देख देयां के जेडे टूल असी पहला ही वर्त रहे हैं वो इस चीज नू किमे संबाल देयां। HTTP PUT Method असल विच डिजाइन दे हिसाब नाल ही एडेमपोटेंट है। ज़़ो तुसी कोई PUT Request पेज देयो ता तुसी असल विच ए कह रहे हों देयो के इस URL ते मजूद पहली वार विच कंटेंट बधल जानद है अते अगलियां चार वारा विच ए सिरफ ओसे चीजनू दबारा सेट करद है इस करके पुट रिक्वेस्ट्स लेए री ट्राई करना कुदर्ती तौरते सुरख्य थुनद है अलाकि एत्थे दिक्कत ओदों आ सकती है जदो कोई पार पर बुन्यादी तौरते ए वर्ब खुद इसतरा बणे है के वार वार होन वाली प्रिक्रियानू बिना कोई वक्रे रिकॉर्ड बनाए संभाल लेंदा है। इस सिंक्रोनाइजेशन दी एक आम समस्या दा बहुत ही वधिया हाल है। पर पोस्ट दी कहानी बिलकुल वक्री है। इसलेई जेकर तुसी टाइम आउट कारण पोस्ट नू रीट्राई कर देओ ता डुपलिकेट रिसोर्स बननदा या इस तो भी माड़ा डुपलिकेट पेमेंट चार्ज होनदा बहुत वड़ा खत्रा रहनदा है इसनू ही पोस्ट चैलेंज किहा जानदा है जे सर्वर ने पह इसनु ठीक करन लई, सानु युनीक आइडम पोटेंसी कीज वर्गियां चीजां दी वर्तों करके, पोस्ट दे उपर मैनुवली आइडम पोटेंसी दी लेयर लगाउनी पैन दी है। जे कर तुसी अजेहा नहीं कर दे, था तो हड़ा सिस्टम डबल एंट्री बग्ज ली हमे ये चार स्टेप्स दा एक फ्लो है, चेक करना, प्रोसेस करना, अते स्टोर करना, सब तो पहला, सर्वर ये चेक करदा है कि की उसकोल क्लाइंट वलनों पेज़ी गई हो खास आइडेंटिपोटेंसी की पहला तो मौझूद है, जे करो की मिल जन दी है, ता सर्वर नू पता ल� एक सदारन पर बहुत ही असरदार तरीका है। क्योंकि हर रिक्वेस्ट नू एक तुरंत चेक दी लोड हुंदी है, इसले ही स्टोरिज दी चोन साड़े आर्किटेक्चर दा एक वड़ा फैसला हुंदा है, हाई परफॉर्मेंस एपिएज लही असी अक्सर रैडिस दी वर्तु कर देया, ए बहुत तेज है, बड़ी गिनती होर विकल्प जिमे के डाइलमो डीबी या तो अड़ा प्राइमरी या डीबी एमेस भी काम कर सकतेने, पर ओ हर रिक्वेस्ट विच लेटेंसी वधा सकतेने. इत्थे असल मुकाबला स्पीड और पर्सिस्टेंस दे विच कार है। जे कर थोड़ा रेडिस कैशे डाउन हुजान दा है ताक इतुसी अपनी आइडम पोटेंसी दी गरंटी गुआ बैठोगे। इंटरव्यू विच एक वधिया जवाब इस फेलियर मोड बारे चर्चा कर� यानि ओ समा जिस दोरान तुसी किसे आइडेमपोटेंसी की नू वैलिड मननोगे, जे कोई क्लाइंट चौवी खंटयां बाद रिक्वेस्ट दुबारा भेजदा है, ता की तो अनू अजेवी उसनू ओही पुरानी ट्रांजेक्शन मननना चाहिदा है? शायद नहीं, असी सिस एक बहुत ही common failure mode है जिस दा त्यान रखना जरूरी है इस तो बचन लई तो अड़े client अटे server विच कार ए समझोता होना चाहिदा है कि ओकी इस किन्नी देर तक valid रहन गियां इंटरव्यू विच जे तुसी ए चर्चा कर दे हो कि तुसी business दे हिसाबना ले इस window नू के में set करोग यह ओ था है जित्थे सब कुछ सई होना बहुत ज़रूरी है यह थे कोई समझाथा नहीं चल सकदा जदो कोई user pay बटन ते क्लिक करदा है ता mobile app एक unique idemptancy की generate कर दिये जेकर network कट जावे और app उस बटन नूँ 5 बार retry करे ता payment gateway उसे कीदी वर्तो करके यह यकीनी बढ़ोंदा है क जेकर अजहा ना होवे ता तोहाननू हजारा रीफंड रिक्वेस्टा संबाणिया पैण गिया और एक कमपनी दे अकसले एक बहुत बड़ी मुसीबत बन जावेगी इत्थे एक ही अकसर किसे खास ट्रांजाक्शन या ओडर आईडी नाल जुड़ी हों दिया है जेकर सर्वरन किसे इंटर्व्यू विच इसनो अपनी मुख धारण वजो वर्तना ए साबत करदा है कि तुसी डेटा इंटेग्रेटी दी असल एहमियत नू समझ देओ और ए भी जान देओ कि इस दा कारोबारदे मुनाफेते सिद्धा की असर पेंदा है ए सिरफ टेकनोलोजी दी गल नहीं ह अइडेन्टूब उन्सी कीज दी वर्तों करके सिस्टम में पक्का करदा है कि कार्ट तो ओर्डर तक दा सफर स्थिर रहे पामें इंवेंटरी सर्विस या शिपिंग सर्विस कॉल इक को रिक्वेस्ट कई वार चली जावे फिर भी स्टेट बिल्कुल सही रेंदी है इत्थे � इस नाल इन्वेंटरी उस यूजरली ब्लॉक हो ज़न दी है, जिसनू लगदा है कि उस दी खरीददारी फेल हो गई सी। सही ऐड़ेंट पोटेंसी इस चीज नू रोक दी है, क्योंकि ये क्लाइंट नू उस खास रिक्वेस्ट की दे स्टेटस बारे सुरख्य तरीक के नल प जे तुसी सिस्टम डिजाइन इंटर्विवी विच बैठे हो, अटे इंटर्विवी और तो आनू पुछ दे कि की होवेगा जे क्लाइंट वलो रिक्वेस्ट पे जन्दे तुरंत बाद नेटवर्क फेल हो जावे, ता समझनो के एहे क्वाडेली आईडम पोटेंसी बारे गल एक खास गल जो डिसकस करनी जरूरी है वो है पहला ही प्रोसेस हो चुके सिनारियो बारे आम तौरते तुसी क्लाइंट नो ए दसली 200 हो के या 204 नो कॉंटेंट रिटर्न करोगे कि प्रावा एसा नू पहला ही मिल चुका है सब ठीक है स्टोरेज लेयर विच अटॉमिस सिटी � ता असी असल विच इस गर तो परदा चोक दिता है कि कि में आईडम पुटेंसी नेटवर्क दियां अनुपचातियां फेल होन वालीयां दिकता नूँ सुरख्य तते प्रोसे मंद रीट्राइज विच बदल दिन दिये मेरा मतलब है कि एस दा असल विचार बहुत सुदारण ह जिस विच सानो युनीक आईडम पुटेंसी कीज दी वर्तो करके दखल देन दी लोड हुन दी है असी इस दे चार महत्तो पूर्ण स्टेप्स वाले लॉजिक बारेगाल कीती है पहला की नूँ चेक करना, काम नूँ प्रोसेस करना अथे फिर रेस कंडिशन्स तो बचर लेई अधे यकीनी बढ़ाऊंदा है कि डेटा हमेशा सही रहे, चाहे क्लाइंट किन्नी वार भी री ट्राइ बटन के ओना दबावे, असल प्रोस से योगताली डिजाइन इस तरह कीता जानदा है, इस दे नाल ही आइडेमपोटेंट एपियाइज बारे साधी चर्चा इत्थे खतम अते ओत वाड़े सामने नेटवर्क फेल होन वाला ओ पुराना सवाल रखनगे ता होण तुसी ए समझाओनली पूरी तरह त्यार हो कि केवे आईडेम पुटेंसी कीज अते रैडिस वर्गियां स्टोरेज रन नीतियां डबल बिलिंग नू रोक दिया हन। असल विच ए इंट Core Understanding आते Immediate Retry बारे चर्चा करांगे. Practice कर दे रहो, आते मैं तो अन्नों अगली वीडियो विच मिलांगे.

ਇਸ ਵੀਡੀਓ ਵਿੱਚ ਅਸੀਂ Idempotent APIs ਨੂੰ ਸੌਖੇ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾਉਂਦੇ ਹਾਂ ਅਤੇ Idempotent APIs, Situation, The Situation: The Chaos of Unreliable Networks, Safe Repeated Execution, Definition: Same Request, Same Result, Untitled Slide, Importance: Why We Need Retry Safety, The PUT Standard: Idempotent by Design ਵਰਗੇ ਮਹੱਤਵਪੂਰਨ system design topics ਨੂੰ cover ਕਰਦੇ ਹਾਂ।

ਜੇ ਤੁਸੀਂ system design, backend engineering, distributed systems ਸਿੱਖ ਰਹੇ ਹੋ ਜਾਂ interviews ਲਈ ਤਿਆਰੀ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ episode ਤੁਹਾਨੂੰ idempotent apis ਦੇ ਪਿੱਛੇ ਵਾਲੇ trade-offs, metrics, performance, reliability ਅਤੇ architecture decisions ਨੂੰ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ।

Punjabi ਵਿੱਚ ਸਮਝਾਇਆ

ਸਮੇਂ ਦੇ ਨਿਸ਼ਾਨ
00:00 ਪਰਿਚਯ
01:50 Situation and Unreliable Network Chaos
03:51 Idempotency and Retry Safety
06:41 PUT, POST, and Repeated Request Behavior
08:46 Duplicate Prevention, Storage, and Expiry
11:41 Payments and Order Integrity
13:36 Designing Reliable Idempotent APIs

#SystemDesign #DistributedSystems #BackendEngineering #PunjabiTech