📦
Marketplace & Booking

Inventory Management System

Multi-Warehouse Aur Consistency
💡 Inventory system EK BADA GODAAM NETWORK hai jahan saamaan kai jagah rakha hai aur har jagah ka hisaab REAL TIME mein sahi hona chahiye — warna ya to bik jaayega jo hai nahi, ya pada rahega jo bik sakta tha.

Teen numbers har SKU par: total, reserved, available. Multi-warehouse mein ye per-warehouse hote hain aur ek global view bhi chahiye. Read path (product page par "in stock" dikhana) eventual consistency se chal sakta hai — thoda purana data acceptable hai.

Write path (reserve karna) STRONG consistency maangta hai. Solution: har SKU ki inventory ek hi shard/partition par rakho taaki us SKU ke saare updates serialize hon. Atomic conditional update se oversell rukta hai. Aur har change ka EVENT publish karo taaki analytics, reorder aur search index update ho sakein.

// Read: eventually consistent — cache se, thoda stale chalega
Product page → Redis ("approximately in stock")

// Write: strongly consistent — SKU-wise partition
Reserve → SKU ka owning shard
        → UPDATE ... WHERE (total - reserved) >= qty
        → event publish (inventory.reserved)
📦
Inventory system EK BADA GODAAM NETWORK hai jahan saamaan kai jagah rakha hai aur har jagah ka hisaab REAL TIME mein sahi hona chahiye — warna ya to bik jaayega jo hai nahi, ya pada rahega jo bik sakta tha.
1 / 2
⚡ Quick Recap
  • Read eventual consistency se, write strong consistency se
  • Har SKU ek hi partition par — updates serialize ho jaate hain
  • Har change ek event — analytics, reorder aur search sync ho jaate hain
Is page mein (2 subtopics)

Har inventory change ek event publish karta hai (reserved, released, shipped, restocked). Ye events Kafka se kai consumers tak jaate hain — search index (in-stock filter), analytics, reorder service, aur seller dashboard.

Isse inventory service ko pata bhi nahi hota ki uske data ka kaun kaun use kar raha hai. Naya feature add karna ek naya consumer hai, inventory service mein change nahi. Ye decoupling ka concrete fayda hai.

Inventory Service → Kafka "inventory.events"
   ├→ Search indexer   (in-stock filter update)
   ├→ Reorder service  (threshold cross to purchase order)
   ├→ Analytics        (stock turnover reports)
   └→ Seller dashboard (real-time view)

Order aane par decide karna padta hai ki kaunse warehouse se bhejein. Factors: customer se distance (delivery speed), kya poora order ek jagah mil raha hai (split shipment mehnga hai), aur warehouse ka current load.

Split shipment ka cost bolna important hai — do packets bhejna do guna shipping cost hai. Isliye systems poora order ek warehouse se bhejne ko strongly prefer karte hain, chaahe wo thoda door ho.

💡Tip: AllocationStrategy ko pluggable rakho — peak season mein "fastest delivery" chahiye, normal time mein "cheapest". Business rules badalte rehte hain.