Inventory Management System
Ek hi "quantity" field rakhna sabse badi galti hai. Teen numbers chahiye: TOTAL, RESERVED (order place hua, ship nahi hua), aur AVAILABLE (= total − reserved). Sale AVAILABLE par honi chahiye, total par nahi.
Flash sale mein hazaaron requests ek saath aati hain. Atomic decrement zaroori hai — DB mein conditional update ("UPDATE ... WHERE available >= ?") ya Redis DECRBY. Aur reservation ka TTL rakho: order timeout hone par stock apne aap wapas available ho jaaye.
// Atomic reserve — race condition yahin rukti hai
// affected rows 0 aaye to stock nahi tha
UPDATE inventory
SET reserved = reserved + :qty
WHERE sku = :sku
AND (total - reserved) >= :qty;
class InventoryService {
boolean reserve(String sku, int qty) {
return jdbc.update(RESERVE_SQL, qty, sku, qty) == 1;
}
// Order confirm -> reserved se total dono ghatao
// Order cancel/timeout -> reserved wapas chhodo
}- Teen numbers rakho: total, reserved, available — ek nahi
- Atomic conditional update se oversell rukta hai, read-then-write se nahi
- Reservation par TTL — order timeout hone par stock wapas
TOTAL = godaam mein kitna hai. RESERVED = kitna kisi order ke naam par block hai. AVAILABLE = total − reserved, matlab kitna abhi bech sakte ho.
Order flow: place hone par reserved badhta hai. Ship hone par total aur reserved DONO ghatte hain. Cancel hone par sirf reserved ghatta hai. In teen transitions ko sahi likhna hi is problem ka core hai.
// Place : reserved += qty (available apne aap ghata)
// Ship : total -= qty; reserved -= qty (godaam se nikal gaya)
// Cancel : reserved -= qty (wapas bikne layak ho gaya)Bade systems mein stock kai warehouses mein hota hai. Order aane par decide karna padta hai ki kaunse warehouse se bhejna hai — customer ke sabse nazdeek waala, ya jahan poora order ek saath mil jaaye (split shipment se bachne ke liye).
Ye AllocationStrategy interface banata hai. Aur batao ki split shipment mehnga hota hai, isliye systems poora order ek warehouse se bhejne ko prefer karte hain.