This project is a design-focused system architecture study that compares how e-commerce and quick-commerce platforms differ at a fundamental level — not in UI, but in backend architecture, data consistency, scalability, and operational complexity.
The goal is to demonstrate systems thinking by translating business promises into technical design decisions.
The order API synchronously reserves inventory in Redis using TTL-based reservation tokens. Only after the reservation succeeds do we persist the order and emit Kafka events. A background reaper reconciles expired reservations to prevent stock leaks.
At a surface level, e-commerce and quick-commerce appear similar:
- browse items
- place an order
- receive delivery
In reality, they are architecturally opposite systems.
A delivery promise of days versus minutes completely reshapes backend design.
This project answers:
- Why Kafka works well for e-commerce but not everywhere in quick-commerce
- Why eventual consistency is acceptable in one system and dangerous in another
- Why some systems must trade cost efficiency for speed
Examples: Amazon, Flipkart, Myntra
- Delivery in 2–5 days
- Lowest possible cost
- Massive scale
- Centralized warehouses
- Batch-oriented processing
- Event-driven workflows
- Eventual consistency
- Retry-friendly operations
Order → Warehouse Allocation → Shipping → Delivery
Failures are tolerated and compensated later.
Examples: Blinkit, Zepto, Instamart
- Delivery in 10–15 minutes
- Hyper-local fulfillment
- Speed over cost
- Store-level inventory
- Stronger consistency guarantees
- Real-time decision making
- Low tolerance for retries
- Operationally complex systems
Order → Inventory Reservation → Store Assignment → Rider Dispatch → Delivery
Failures must be handled immediately.
| Dimension | E-Commerce | Quick-Commerce |
|---|---|---|
| Delivery SLA | Days | Minutes |
| Inventory | Centralized | Hyper-local |
| Consistency | Eventual | Near-strong |
| Latency tolerance | High | Very low |
| Primary optimization | Cost | Speed |
| Failure handling | Retry & compensate | Immediate fallback |
| CAP bias | AP-leaning | CP-leaning |
- Inventory updates are asynchronous
- Overselling is tolerated
- Reconciliation happens later
- Kafka-based propagation
- Inventory must be reserved synchronously
- Stock locks with TTL
- Redis / in-memory systems
- Overselling is unacceptable
Inventory correctness is optional in e-commerce, mandatory in quick-commerce.
- Kafka-first architecture
- Async order processing
- Loose coupling
- Replay-friendly systems
- Hybrid architecture
- Synchronous inventory & rider assignment
- Events used only after critical decisions
- Real-time APIs dominate
- Warehouse delay → notify user
- Inventory mismatch → reconcile
- Delivery delay → acceptable
- Item unavailable → reroute store
- Rider unavailable → reassign instantly
- Traffic spike → throttle orders
In quick-commerce, failures are customer-visible immediately.
- Lag tolerated
- Batch metrics
- SLA measured in hours
- Real-time alerts
- SLA measured in seconds
- Metrics include:
- picker time
- rider ETA
- store distance
- fulfillment success rate
The same domain requires radically different architectures when business constraints change.
This project highlights why:
- tools cannot be blindly reused
- architecture must follow business reality
- consistency, latency, and cost are always tradeoffs
- Translation of business SLAs into system architecture
- Tradeoff analysis (consistency vs latency vs cost)
- Real-world system design reasoning
- Staff-level architectural judgment
This project intentionally focuses on thinking, not implementation.
A comparative system design study showing how e-commerce and quick-commerce architectures diverge due to fundamentally different business promises.