Problem Scope & Requirements
Quick-commerce platforms demand guaranteed 10-minute grocery delivery from hyper-local Micro Fulfillment Centers (MFCs).
Functional Requirements
- Real-time catalog and inventory availability per geographic geo-fence (radius 2.5km).
- Atomically reserve stock during the 7-minute checkout window without double-selling scarce items.
- Dispatch nearest available courier rider via dynamic batch routing.
Non-Functional Targets
- Availability: 99.99% for search & checkout flows.
- Latency: Sub-80ms p95 for catalog search; sub-150ms for cart reservation.
- Peak Throughput: 45,000 orders/minute during flash grocery promotions.
High-Level Architecture
architecture/dispatch-topology.txt
[Mobile Client / Web App]
│
▼
[Global Edge CDN / Anycast]
│
▼
[API Gateway & Rate Limiter]
┌─────┴──────────────────┐
▼ ▼
[Catalog Service] [Reservation & Order Service]
│ (Read-heavy) │ (Write-heavy / ACID)
▼ ▼
[Redis Geo + Elastic] [Redis Redlock + CockroachDB / PG]
│
▼
[Kafka Event Stream]
│
┌──────┴──────┐
▼ ▼
[Rider Dispatch] [WMS MFC Picker]Inventory Locking Strategy
To avoid database row-level locking bottlenecks under 40k+ concurrent requests, we employ a distributed two-phase token reservation in Redis:
- Pre-decrement in Redis: Execute a Lua script checking current stock and decrementing if
stock >= requested. - TTL Expire Key: Store reservation token with a 420-second TTL (
SET res:{order_id}:{item_id} qty EX 420). - Commit on Payment Confirmation: Background worker acknowledges the payment webhook and flushes the decremented delta asynchronously to PostgreSQL.
- Rollback on Timeout: Expired reservations emit a keyspace notification triggering automatic stock re-increment.
Personal engineering field notes compiled from production systems. Patterns and benchmarks are updated as runtimes evolve.