Quick Commerce System (Flipkart Minutes)
Design Flipkart Minutes — instant delivery for any item with customer and partner onboarding, queued order assignment, pickup/delivery lifecycle, and thread-safe concurrency.
Implement the core system for Flipkart Minutes, Flipkart's instant delivery platform, enabling customers to order any item for delivery within minutes — with rapid assignment, queueing, and reliable fulfillment.
This one tests whether you can model a real-time fulfillment loop cleanly — queued assignment under constrained supply, strict one-order-per-partner invariant, cancellable-before-pickup semantics, and thread-safe state transitions — without leaking order, partner, and queue concerns into one another.
Objective
The primary objective is to design and implement an in-memory quick commerce system that supports onboarding of customers and delivery partners, order placement and cancellation, auto-assignment with queueing, pickup and delivery transitions, real-time status tracking, and correct concurrency — plus bonus extensibility around notifications, ratings, dashboards, and auto-cancellation.
Functional Requirements
Requirements are split into two tiers so you know what to prioritize under time pressure: build first, and build only after the core is demoable.
Part 1 — Core Requirements
Core functionality you must build and get working first.
1. Onboarding
2. Order Placement & Cancellation
3. Order Assignment & Fulfillment
4. Status Tracking
5. Concurrency & Thread Safety
The system must be thread-safe — multiple customers and partners act simultaneously (place, cancel, pickup, deliver, query). Assignment, queue dequeue, and status transitions must be correctly synchronized.
Part 2 — Bonus Features
Extensibility checks — can your design layer notifications, ratings, and ops dashboards on top without rewriting the assignment core.
Example Usage: Sample Flow
Driver shape — inputs shown as i: and outputs as o:; exact format is flexible as long as semantics match.
1. Onboard customers and partners
> onboard customer — customer_id: c1, name: Alice
✅ Customer c1 onboarded.
> onboard delivery_partner — partner_id: p1, name: Bob
✅ Partner p1 onboarded. Status: AVAILABLE
> onboard delivery_partner — partner_id: p2, name: Charlie
✅ Partner p2 onboarded. Status: AVAILABLE
2. Create orders — auto-assignment & queueing
> create order — customer_id: c1, item_name: "Milk"
✅ Order o1 created → ASSIGNED to p1
> create order — customer_id: c1, item_name: "Bread"
✅ Order o2 created → ASSIGNED to p2
> create order — customer_id: c1, item_name: "Eggs"
✅ Order o3 created → QUEUED (no partner available)
3. Show status
> show order status — order_id: o1
📦 o1 — ASSIGNED (partner: p1)
> show delivery partner status — partner_id: p1
🛵 p1 — BUSY (order: o1)
> show order status — order_id: o3
📦 o3 — QUEUED
4. Pickup and delivery transitions
> pick up order — partner_id: p1, order_id: o1
✅ o1 → PICKED_UP (cannot be canceled now)
> complete order — partner_id: p1, order_id: o1
✅ o1 → DELIVERED — p1 becomes AVAILABLE → o3 auto-assigned to p1
> show order status — order_id: o3
📦 o3 — ASSIGNED (partner: p1)
5. Cancel before pickup (frees partner)
> cancel order — order_id: o3
✅ o3 → CANCELED — p1 becomes AVAILABLE
> show delivery partner status — partner_id: p1
🛵 p1 — AVAILABLE
6. Cancel after pickup — blocked
> pick up order — partner_id: p2, order_id: o2
✅ o2 → PICKED_UP
> cancel order — order_id: o2
❌ Cancel failed — order already picked up.
Queuing, one-order-per-partner, cancel-before-pickup, and pickup-lock semantics all hold — a third concurrent order correctly queues when both partners are busy, auto-assigns when a partner frees up, and a queued-but-assigned order that gets canceled before pickup frees its partner without breaking the queue.
Guidelines
You have 120 minutes. Use only in-memory data structures — no external databases like MySQL. No UX or HTTP APIs — a standalone driver / main class / test harness is enough.
The problem expects reasonable assumptions — state them to the reviewer. Examples: order IDs are system-generated, partner selection among AVAILABLE is any / FIFO, and time for auto-cancel is simulated via a clock or scheduler.