stock counter लाई एउटै atomic ठाउँमा राख्नुहोस् र यसलाई atomic रूपमा decrement गर्नुहोस् — Redis DECR (वा Lua script) जसले बाँकी value फर्काउँछ। नतिजा < 0 भए, त्यो request हार्यो; database कहिल्यै concurrency gate होइन। बाँकी सबै अरू 999,000 request लाई सस्तोमा हटाउने बारेमा हो।
1M clients ─▶ CDN/edge (waiting room, drop bots) ─▶ LB
│
Stateless API pods
│
Redis: DECR stock (Lua: check+dec+record)
│hit>=0 │miss<0
▼ ▼
enqueue order ─▶ DB reject "sold out"
DECR stock:sale123 atomic छ — दुई request ले दुवैले "1 बाँकी" पढ्न सक्दैनन्। एउटा Lua script ले यो एउटै round trip मा गर्छ: बाँकी जाँच, decrement, र SADD winners:{sale} {user} record गर्छ ताकि एउटा प्रयोगकर्ताले दुई पटक जित्न नसकोस्। Lua Redis मा single-threaded चल्छ, त्यसैले सम्पूर्ण check-and-set एउटै atomic कदम हो।>= 0) queue मा पठाइन्छन्; worker ले order लाई Postgres मा asynchronous रूपमा लेख्छ। DB ले कहिल्यै 10 लाख concurrent write देख्दैन — केवल ~1000 विजेता write।अन्तर्वार्ताकारले तपाईंले race condition ठ्याक्कै नाम दिनुभएको हेर्न चाहन्छन्: SELECT stock अनि UPDATE दुई statement मा गर्दा दुई request ले दुवैले 1000 पढ्छन् र दुवैले बेच्छन् — classic oversell। "राम्रो" भनेको "transaction / SELECT ... FOR UPDATE प्रयोग गर"; "उत्कृष्ट" भनेको row lock ले 10 लाख request लाई एउटै hot row मा serialize गर्छ र throughput भत्काउँछ भन्ने चिन्नु, त्यसैले तपाईंले contention लाई Redis को single-threaded atomic op मा सार्नुहुन्छ र केवल विजेतालाई मात्र persist गर्नुहुन्छ। जाल भनेको atomicity बिना application-level जाँच (if (stock > 0)) मा भर पर्नु हो।
FOR UPDATE: Redis ले एउटा hot key मा 100k+ ops/s सम्भाल्छ; Postgres row lock ले serialize गर्छ र flash sale मा पग्लन्छ। DB लाई टिकाउ order record का लागि मात्र राख्नुहोस्।विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्