Blinkit / Grocery Delivery

Amazon interviews often feature system design questions on grocery delivery platforms like Blinkit (a quick-commerce service formerly Zomato Hyperpure), focusing on backend scalability, e-commerce flows, web APIs, and ML integrations for personalization or demand prediction. No exact public match exists for a verbatim "Blinkit / Grocery Delivery" problem with those precise tags and full I/O examples/constraints, as Amazon's questions are typically verbal or behind NDA. However, based on common patterns from reported experiences, here's a reconstructed comprehensive version drawn from similar designs (e.g., 10-minute delivery systems).[1][2]

Problem Statement

Design a scalable backend system for Blinkit, an ultra-fast grocery delivery service promising 10-minute deliveries within a 3-5 km radius of dark stores (micro-warehouses). Handle high concurrency (peaks of 1,000+ orders/min per store), real-time inventory, dynamic pricing via ML, order assignment to delivery partners, ETA predictions, and payment processing. Key challenges: Minimize stock-outs (target <1%), ensure 99.9% uptime, optimize rider assignment amid traffic/variables, and scale to 100+ cities with millions of DAU. Incorporate ML for demand forecasting and personalized recommendations.[4][6]

Functional Requirements

• User search/browse groceries with filters (price, category, brand).
• Real-time serviceability check (can deliver to pincode in 10 min?).
• Add to cart, checkout with payments (UPI/cards), apply coupons.
• Assign nearest available rider; track order live with ETA updates.
• Handle cancellations/refunds; post-delivery ratings.
• Admin: Monitor dark store inventory, re-stock alerts, analytics.[2][6]

Non-Functional Requirements & Constraints

| Aspect | Requirement/Constraint | |--------|------------------------| | Scale | 10M DAU, 100K QPS peak, 500 dark stores. [6] | | Latency | Search/ETA <200ms; end-to-end order <10s. | | Availability | 99.99% (use geo-redundant stores). | | Consistency | Strong for inventory/payments (CAP: CP over AP). | | Data | 1TB+ daily logs; GDPR-compliant. | | Peak Load | 20% order rejection rate in 7-9 PM slots if understaffed. [4] | | Cost | <$1/order; redundant riders (2x capacity). [4] |

Input/Output Examples

No verbatim I/O from Amazon sources, but typical API examples from similar designs:

1. Search Products
   Input: POST /search { "pincode": "110001", "query": "milk", "lat": 28.6139, "lon": 77.2090 }
   Output: { "products": [{ "id": 123, "name": "Amul Milk", "price": 60, "stock": 500, "eta": "8min", "serviceable": true }], "recommendations": [...] }[6]

2. Place Order
   Input: POST /order { "user_id": "u123", "items": [{"product_id": 123, "qty": 2}], "payment": { "method": "UPI" } }
   Output: { "order_id": "o456", "status": "assigned", "eta": "9min", "rider_id": "r789" }
   Constraint: Fail if inventory < qty or !serviceable.[2]

3. Track Order
   Input: GET /track/{order_id}
   Output: { "status": "out_for_delivery", "current_lat": 28.62, "eta": "2min" } (WebSocket for live updates).[6]

High-Level Design Components

• Services: User, Catalog (ES for search), Inventory (sharded MySQL + Redis), Order, Payment (Saga pattern), Rider Matching (ML-based graph shortest path), ETA Predictor (LSTM model).[6]
• DBs: DynamoDB (orders), Cassandra (logs), Kafka (events), Redis (caches/inventory locks).
• ML Integration: Demand forecast per SKU/pincode; rider assignment via reinforcement learning.[4]
• Bottlenecks: Inventory contention (use optimistic locking); ETA accuracy (factor traffic via external APIs).[4]

This compiles reported elements; actual Amazon questions evolve (e.g., emphasize trade-offs like sharding vs. replication). Practice scaling to 10x load.[8]