🛒
Commerce & Payments

E-Commerce Platform

Catalog, Cart, Order Aur Inventory
💡 E-commerce platform EK BADA BAAZAAR hai jisme alag-alag dukaanein hain — catalog, cart, order, payment, inventory. Sabse badi samajh ye hai ki inhe EK system maanna galti hai; ye alag services hain jinki scaling needs bilkul alag hain.

Ye system READ-HEAVY hai — browse aur search, order se 100x zyada hote hain. Isliye catalog ko heavily cache karo aur search ke liye alag engine (Elasticsearch) rakho jo DB se async sync ho. Product page ko CDN se serve karo.

Order placement WRITE path hai aur yahan consistency chahiye. Order banate waqt inventory RESERVE hoti hai (available = total − reserved), payment hone par confirm. Ye teen alag services hain, isliye Saga pattern se orchestrate karo. Aur order history ko append-only event log maano — order ka current state events se derive ho.

// Read path (99% traffic) — heavily cached
Browse → CDN → Catalog Service → Redis → DB (read replicas)
Search → Elasticsearch (async sync from catalog DB)

// Write path (1%) — consistency chahiye
Place Order → Saga:
   reserveInventory → chargePayment → confirmOrder → notifyUser
   (koi bhi step fail => pichhle steps ka compensating action)
🛒
E-commerce platform EK BADA BAAZAAR hai jisme alag-alag dukaanein hain — catalog, cart, order, payment, inventory. Sabse badi samajh ye hai ki inhe EK system maanna galti hai; ye alag services hain jinki scaling needs bilkul alag hain.
1 / 2
⚡ Quick Recap
  • Read-heavy: catalog cache + CDN + alag search engine
  • Order path par Saga — inventory, payment, order alag services hain
  • Flash sale ke liye Redis atomic counter + queue
Is page mein (2 subtopics)

Product search ko SQL LIKE query se karna scale par kaam nahi karta — na full-text relevance milti hai, na typo tolerance, na faceted filters. Isliye Elasticsearch jaisa search engine alag rehta hai.

Search index catalog DB se ASYNC sync hota hai (change data capture ya events se). Iska matlab hai eventual consistency — naya product search mein aane mein kuch second lag sakte hain. Ye acceptable hai aur ise explicitly bolna chahiye.

Catalog DB → CDC / events → Kafka → Indexer → Elasticsearch

// Search index thoda peeche reh sakta hai (seconds).
// Product detail page hamesha catalog DB se — wahan staleness
// acceptable nahi hai.

Order ka current status ek mutable column mein rakhne ke bajaye, order ke saare EVENTS store karo — OrderPlaced, PaymentCaptured, Shipped, Delivered. Current state in events se derive hoti hai.

Fayde: poora audit trail free milta hai ("order kab aur kyun cancel hua" ka exact jawab), debugging aasaan hoti hai, aur naye consumers (analytics, loyalty) purane events replay kar sakte hain. Cost ye hai ki reads ke liye snapshot rakhna padta hai.

💡Tip: Event sourcing har jagah mat lagao — ye order jaise workflow-heavy domains ke liye achha hai, par product catalog jaise simple CRUD ke liye over-engineering hai.