# Shopify ले इन्भेन्टरी रिजर्भेसन MySQL मा सार्यो

Published: 2026-10-10

Shopify ले आफ्नो इन्भेन्टरी रिजर्भेसन प्रणाली Redis बाट MySQL डाटाबेसमा सार्यो जुन पहिले नै इन्भेन्टरी लेजर राखिरहेको थियो। व्यक्तिगत रूपमा लक गर्न सकिने इकाई पङ्क्तिहरूको एक बाउण्डेड पूलले एक साथ चेकआउटहरूलाई SKIP LOCKED प्रयोग गरेर विभिन्न योग्य एकाइहरू चयन गर्न दिन्छ। यो डिजाइन लेनदेन सीमाहरू, प्राथमिक-कुञ्जी लेआउट, पुनःपूर्ति नियमहरू र चेकआउटभरि जडान होल्ड समय अवलोकनमा पनि निर्भर गर्दछ।

Canonical: https://thedailydiff.dev/ne/video/shopify-reservation-locks/

## यो भिडियोले के समेट्छ

- पुरानो Redis मात्रा-काउन्टर मोडेलले एक साथ काम गर्ने क्षमता ह्यान्डल गर्‍यो, तर रिजर्भेसन सफा गर्ने र MySQL लेजर अपडेटले एकल स्थानीय एटोमिक लेनदेन साझा गर्न सकेन।
- प्रतिस्थापनले वस्तु/स्थान संयोजनमा प्रति 1,000 मा सीमित पूलमा प्रत्येक उपलब्ध एकाइको लागि एउटा पङ्क्ति प्रयोग गर्दछ। खाली पूलले पुनःपूर्ति लक पछाडि पर्खिरहेका एक साथ अनुरोधहरूको साथ इनलाइन पुनःपूर्ति ट्रिगर गर्न सक्छ।
- कम्पोजिट प्राइमरी कुञ्जी (shop\_id, inventory\_item\_id, inventory\_group\_id, id) हो। Shopify ले यसको प्रोटोटाइपमा लक ओभरहेड घटायो र READ COMMITTED प्रयोग गर्‍यो ताकि पुनःपूर्तिलाई अवरुद्ध गर्ने ग्याप लकहरूबाट बच्न सकियोस्।
- रिजर्भले रिजर्भेसन रेकर्डहरू घुसाउनु अघि पूल पङ्क्तिहरू मेटाउँछ। कमिट गर्दा डाटाबेस लकहरू रिलिज हुन्छन् जबकि भण्डारित होल्ड भुक्तानीभरि रहन्छ; सफल भुक्तानीले लेजर दाबी गर्दछ र पछिको एटोमिक लेनदेनमा रिजर्भेसन हटाउँछ।
- MySQL ले SKIP LOCKED लाई लक गरिएका पङ्क्तिहरू छोड्ने असंगत दृश्यको रूपमा दस्तावेज गर्दछ। यसले पूर्ण स्टक गणना वा निष्पक्ष पालो-लिन स्थापित गर्दैन, पङ्क्ति-स्तर लकहरूमा मात्र लागू हुन्छ र कथन-आधारित प्रतिकृतिको लागि असुरक्षित छ।
- स्रोत उदाहरणमा expires\_at समावेश छ, तर Shopify ले MySQL म्याद सकिने-सफा गर्ने एल्गोरिदमलाई दस्तावेज गर्दैन। भिडियोको रिलिज/म्याद सकिने शाखा एक व्याख्यात्मक जीवनचक्र आवश्यकता हो।
- अन्य चेकआउट कोडमा जडान होल्ड समय अन्तिम थ्रुपुट बाधाहरू थिए। Shopify ले दुवै प्रणालीलाई छाया-लेख्यो, परिणामहरू तुलना गर्‍यो र Redis किल-स्विच फलकको साथ बिस्तारै स्विच गर्‍यो।

## अध्यायहरू

- 0:00 रिजर्भेसन MySQL मा किन सार्ने?
- 0:29 दुई स्टोर किन जोखिमपूर्ण थिए?
- 0:52 लक गर्न सकिने एकाइ के बन्छ?
- 1:15 जब पूल खाली हुन्छ तब के हुन्छ?
- 2:14 SKIP LOCKED ले के छोड्छ?
- 2:26 वास्तविक सीमा कहाँ थियो?
- 2:38 मैले यो डिजाइन किन पठाउनु पर्छ?

## अनुवादित ट्रान्सक्रिप्ट

मूल अंग्रेजी कथाबाट अनुवादित। उपलब्ध अडियो र क्याप्सनहरू YouTube द्वारा नियन्त्रित हुन्छन्।

### रिजर्भेसन MySQL मा किन सार्ने?

0:00 एक चेकआउटलाई छिटो रहन Redis चाहिन्छ। Shopify ले इन्भेन्टरी रिजर्भेसन MySQL मा सार्यो, प्रत्येक एकाइको लागि एउटा पङ्क्ति प्रयोग गरेर बाउण्डेड पूलमा। MySQL किन छान्ने? लकहरू कसरी सुरक्षित रूपमा छोड्ने? यो द डेली डिफ, भित्रबाट हो। र किन छिटो प्रश्नहरूले अझै सीमामा हिट गर्‍यो? Shopify अनलाइन र व्यक्तिगत रूपमा बेच्नको लागि एक वाणिज्य प्लेटफर्म हो। Redis एक इन-मेमोरी डाटा स्टोर हो।

0:21 MySQL एक रिलेसनल डाटाबेस हो, र Shopify ले पहिले नै आफ्नो इन्भेन्टरी लेजर राखेको थियो त्यहाँ। एक रिजर्भेसनले क्रेताले भुक्तानी गर्दा छोटो समयको लागि स्टक राख्छ।

### दुई स्टोर किन जोखिमपूर्ण थिए?

0:29 तिनीहरूको Redis मोडेलले वस्तु काउन्टर घटाउँछ। भुक्तानी गरिएको अर्डर दाबी गर्नु भनेको MySQL लेजर अपडेट गर्नु र Redis सफा गर्नु थियो। ती अलग लेख्ने कार्यहरूले स्टकलाई दुई पटक बेचेको वा उपलब्ध नभएको अवस्थामा छोड्न सक्छ जब यो बेच्न योग्य हुनुपर्छ। पुरानो मोडेलमा स्थान जागरूकताको पनि अभाव थियो। प्रतिस्थापनले कतैबाट स्टक छान्नुपर्छ जसले अर्डर पूरा गर्न सक्छ। गलत महाद्वीपमा रहेको गोदामले उत्कृष्ट डाटाबेस प्रविष्टि र एक डरलाग्दो डेलिभरी प्रतिज्ञा बनाउँछ। पहिलेका MySQL प्रयासहरूले मात्रा पङ्क्ति प्रयोग गर्थे, त्यसैले प्रतिस्पर्धा गर्ने चेकआउटहरू

### लक गर्न सकिने एकाइ के बन्छ?

0:56 एउटै ताला अगाडि लामबद्ध थिए। स्प्रेडसिट सेल वरपरको भेलभेट रोपको कल्पना गर्नुहोस्। थप कामदारहरू थप्दा मात्र लाम लामो हुन्छ। Shopify ले लक गर्न सकिने वस्तु परिवर्तन गर्‍यो। प्रत्येक उपलब्ध एकाइले आफ्नै पङ्क्ति पाउँछ। एक लकिङ रिडले अर्को लेनदेनले राखेका एकाइहरू छोड्छ र अन्य योग्य एकाइहरू चयन गर्दछ। विभिन्न कामदारहरूले विभिन्न पङ्क्तिहरू प्राप्त गर्न सक्छन्, जबकि हट काउन्टर तिनीहरूको बाटोबाट बाहिर रहन्छ।

### जब पूल खाली हुन्छ तब के हुन्छ?

1:15 त्यो पूल प्रति वस्तु र स्थान हजार पङ्क्तिमा सीमित छ। पुनःपूर्ति लेजरबाट लिइन्छ। यदि यो खाली भयो भने, रिजर्भ पाथले इनलाइन पुनःपूर्ति गर्दछ, प्रतिस्पर्धा गर्ने अनुरोधहरू पुनःपूर्ति लक पछाडि पर्खिरहेका हुन्छन्। खाली पूलको अर्थ खाली गोदाम होइन। रिजर्भले चयन गरिएका पूल पङ्क्तिहरू मेटाउँछ, त्यसपछि लेनदेनमा रिजर्भेसन रेकर्डहरू घुसाउँछ। कमिटले डाटाबेस लकहरू रिलिज गर्दछ।

1:35 रोलब्याकले परिवर्तनहरू रद्द गर्दछ। रिजर्भेसन भुक्तानी प्रक्रियाभरि भण्डारित अवस्थाको रूपमा रहन्छ। सफल भुक्तानीले लेजर दाबी गर्दछ र रिजर्भेसनलाई परमाणु रूपमा हटाउँछ। डाटाबेस लकहरूले भुक्तानी फारमको हेरचाह गर्न कहिल्यै आवश्यक पर्दैन। तिनीहरूको कम्पोजिट प्राइमरी कुञ्जी पसल, वस्तु, समूह, त्यसपछि एकाइ पहिचानबाट सुरु हुन्छ। लुकअप मिलाउँदा तिनीहरूको प्रोटोटाइपमा अनुक्रमणिका लकिङ घट्यो। तिनीहरूले पूल पुनःपूर्तिलाई अवरुद्ध गर्ने ग्याप लकहरूबाट बच्न पढिएको कमिटेड पनि प्रयोग गर्छन्,

1:57 र गोलाकार प्रतीक्षा रोक्न एक सुसंगत तालिका क्रम। प्रकाशित उदाहरणले म्याद सकिने समय रेकर्ड गर्दछ। छोडिएका भुक्तानीहरूलाई अन्ततः स्टक रिलिज गर्न आवश्यक छ, वा किनमेल कार्ट एक जग्गाधनी बन्छ। Shopify को पोस्टले त्यो सफा गर्ने एल्गोरिदमलाई अनिर्दिष्ट छोड्छ, त्यसैले यो रेखाचित्रले जीवनचक्र आवश्यकता देखाउँछ। यहाँ क्याच छ।

### SKIP LOCKED ले के छोड्छ?

2:14 लक गरिएका पङ्क्तिहरू SKIP LOCKED ले बाहिर निकाल्छ, त्यसैले म्यानुअलले यसको परिणामलाई असंगत दृश्य भन्छ। यसले न त पूर्ण स्टक गणना प्रदान गर्दछ न त निष्पक्ष पालो-लिन। उपलब्धता निर्णय र पुनःपूर्ति नियमहरू यसको वरिपरि राख्नुहोस्।

### वास्तविक सीमा कहाँ थियो?

2:26 र त्यो सीमा? अन्य चेकआउट कोडले डाटाबेस जडानहरू धेरै लामो समयसम्म राखिरहेको थियो। Shopify ले कलरहरूलाई ट्याग गर्‍यो र जडान होल्ड समय मापन गर्‍यो, त्यसपछि चेकआउट पाथ सफा गर्‍यो र थ्रेडको समवर्तीतालाई पुनरावलोकन गर्‍यो। छिटो प्रश्नहरूले अझै प्रश्न बाहिर लामबद्ध हुन सक्छ।

### मैले यो डिजाइन किन पठाउनु पर्छ?

2:38 तिनीहरूले Redis आधिकारिकको साथ दुवै प्रणालीलाई छाया-लेखे, परिणामहरू तुलना गरे, त्यसपछि किल स्विचको साथ बिस्तारै स्विच गरे। मेरो निर्णय SHIP IT हो। म साझा लेनदेन सीमा र त्यो रोलब्याकेबल रोलआउट पठाउनेछु, सम्पूर्ण चेकआउट पाथ इन्स्ट्रुमेन्ट गरिएको साथ। यस बारेमा प्रश्न छ? टिप्पणीहरूमा राख्नुहोस्। र त्यो आजको लागि फरक छ।

2:54 म Axrisi बाट निको हुँ। जिम्मेवारीपूर्वक मर्ज गर्नुहोस्।

## स्रोतहरू

- [We replaced Redis with MySQL for inventory reservations—and it scaled](https://shopify.engineering/scaling-inventory-reservations) — Shopify Engineering — Emilie Noel
- [Simplified reservation SQL embedded in Shopify's article](https://gist.github.com/CourtneySymons/cb5ecbe86331047aae166d5b1f1d555c) — Shopify Engineering / CourtneySymons on GitHub Gist
- [MySQL 8.0 — Locking Reads](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html) — Oracle / MySQL Reference Manual
- [MySQL 8.0 — Transaction Isolation Levels](https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html) — Oracle / MySQL Reference Manual
- [What Is Shopify and How Does It Work?](https://www.shopify.com/blog/what-is-shopify) — Shopify
- [Redis quick starts](https://redis.io/docs/latest/develop/get-started/) — Redis documentation
- [What is MySQL?](https://dev.mysql.com/doc/refman/8.0/en/what-is-mysql.html) — Oracle / MySQL Reference Manual