stock counter ને એક જ atomic જગ્યાએ રાખો અને તેને atomically decrement કરો — એક Redis DECR (અથવા Lua script) જે બાકી રહેલી value return કરે. જો પરિણામ < 0 હોય, તો તે request હારી; database ક્યારેય concurrency gate નથી. બાકી બધું બીજી 999,000 requests ને સસ્તામાં shed કરવા વિશે છે.
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 છે — બે requests બંને "1 બાકી" વાંચી શકતી નથી. એક Lua script તે એક જ round trip માં કરે છે: બાકી check કરે, decrement કરે, અને SADD winners:{sale} {user} record કરે જેથી એક યુઝર બે વાર જીતી ન શકે. Lua Redis પર single-threaded ચાલે છે, તેથી આખું check-and-set એક atomic step છે.>= 0) queue માં push થાય છે; એક worker order ને asynchronously Postgres માં લખે છે. DB ક્યારેય 1M concurrent writes જોતું નથી — માત્ર ~1000 winner writes.ઇન્ટરવ્યૂઅર તમને race condition ને ચોકસાઈથી નામ આપતા જોવા માંગે છે: SELECT stock પછી બે statements માં UPDATE બે requests ને બંને 1000 વાંચવા અને બંને ને વેચવા દે છે — classic oversell. "Good" એ છે "transaction / SELECT ... FOR UPDATE વાપરો"; "great" એ ઓળખવું છે કે row locks 1M requests ને એક hot row પર serialize કરે છે અને throughput તૂટી પડે છે, તેથી તમે contention ને Redis માં એક single-threaded atomic op પર ખસેડો છો અને માત્ર winners ને persist કરો છો. Trap એ atomicity વગર application-level checks (if (stock > 0)) પર ભરોસો કરવાનું છે.
FOR UPDATE: Redis એક hot key પર 100k+ ops/s સંભાળે છે; એક Postgres row lock serialize કરે છે અને flash sale હેઠળ melt થાય છે. DB ને durable order records માટે reserve રાખો.વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો