stock counter ను ఒకే atomic స్థలంలో ఉంచి దానిని atomic గా decrement చేయండి — మిగిలిన విలువను return చేసే Redis DECR (లేదా Lua script). ఫలితం < 0 అయితే, ఆ request ఓడిపోయింది; database ఎప్పుడూ concurrency gate కాదు. మిగిలినదంతా ఇతర 999,000 requests ను చవకగా వదిలించుకోవడం గురించి.
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 మిగిలింది" అని read చేయలేవు. ఒక 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 ను Postgres కి asynchronously వ్రాస్తుంది. DB ఎప్పుడూ 1M concurrent writes చూడదు — కేవలం ~1000 winner writes మాత్రమే.మీరు race condition ను ఖచ్చితంగా పేర్కొనడం ఇంటర్వ్యూయర్ చూడాలనుకుంటారు: రెండు statements లో SELECT stock తర్వాత UPDATE — రెండు requests రెండూ 1000 ను read చేసి రెండూ sell చేస్తాయి — classic oversell. "మంచిది" అంటే "transaction / SELECT ... FOR UPDATE వాడండి"; "గొప్పది" అంటే row locks 1M requests ను ఒకే hot row పైకి serialize చేసి throughput ను కుప్పకూలుస్తాయని గుర్తించడం, కాబట్టి మీరు contention ను Redis లోని single-threaded atomic op కి తరలించి winners ను మాత్రమే persist చేస్తారు. ఉచ్చు — atomicity లేకుండా application-level checks (if (stock > 0)) ను నమ్మడం.
FOR UPDATE: Redis ఒక hot key పై 100k+ ops/s ను handle చేస్తుంది; Postgres row lock flash sale లో serialize అయి కరిగిపోతుంది. durable order records కోసం DB ను reserve చేయండి.జూనియర్ నుండి సీనియర్ వరకు వివరణాత్మక సమాధానాలతో IT ఇంటర్వ్యూ ప్రశ్నల లైబ్రరీ.
విరాళం