Katkat
Back

Design a Coffee-Shop Order-Management System

SalesforceSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design a distributed order-management system for a multi-location coffee shop chain, focusing on transactional order states, menu snapshotting, idempotent payment processing, and resilient preparation workflows.

Scenario

Design an end-to-end Order-Management System (OMS) for a high-volume coffee shop chain with thousands of retail locations. The system must support digital orders placed via mobile apps, kiosk terminals, and physical POS registers, coordinating order submission through payment processing and kitchen (barista) fulfillment.

Requirements

Functional Requirements

  1. Menu & Customization Snapshot: Customers can browse current items, modifiers (e.g., oat milk, extra shot), and store-specific pricing. When an order is placed, an immutable snapshot of prices and item configurations must be preserved, insulating active orders from mid-day menu or pricing updates.
  2. Order Lifecycle State Machine: Manage strict status transitions: CREATED -> PAYMENT_PENDING -> PAID -> QUEUED -> PREPARING -> READY -> COMPLETED (or CANCELLED / REFUNDED).
  3. Payment Coordination & Idempotency: Safely charge third-party payment gateways with zero double-billing and robust handling of network timeouts or partial failures.
  4. Barista Queue Dispatch: Transmit paid orders to kitchen display systems (KDS) at the designated store in real time, supporting queue prioritization (e.g., hot beverages vs. cold grab-and-go).
  5. Failure Recovery: Reconcile edge cases such as successful charges with dropped order confirmations, terminal disconnections, or abandoned prep items.

Non-Functional Requirements

  • Scale: 2,500 stores, each handling up to 300 peak orders per hour (~210 orders/second globally at peak).
  • Latency: Order submission response < 250ms (p99); Barista KDS updates within 1 second of payment completion.
  • Consistency: Strong consistency for financial transitions and order status updates. Eventual consistency is acceptable for store sales analytics.
  • Availability: 99.99% uptime for order intake and POS operation.

Key Deliverables

  • API Design: Endpoints for creating an order, capturing payment, and updating prep states.
  • Data Model: Core schemas showing how menu snapshots, orders, payments, and fulfillment events are persisted.
  • Architecture & Workflows: Core services, message brokers, state management, and the coordination pattern used to orchestrate payments and kitchen dispatch (e.g., transactional outbox, saga).
  • Failure Modes & Trade-offs: Strategies for handling gateway timeouts, network partitions at physical stores, and concurrent state transitions.

Hints

Hint 1

To prevent menu price alterations from corrupting inflight orders, decouple active catalog items from line items by embedding a frozen JSON snapshot of item names, IDs, modifiers, and unit prices directly onto the order record.

Hint 2

Use a unique client-generated idempotency key combined with a Transactional Outbox pattern so that updating order state to PAID and publishing to the kitchen queue happen atomically in the database.

Hint 3

For kitchen terminals prone to spotty in-store connectivity, combine local SQLite caching on the POS/KDS with server-sent events (SSE) or WebSockets backed by sequence-numbered replay logs.

Follow-up questions

  • How would you handle a scenario where an external payment provider charges the customer, but the network drops before returning a response to your Order Service?
  • If a popular modifier (e.g., oat milk) runs out of stock while 20 customers have it in their carts, how does the system prevent overselling without blocking concurrent read traffic?
  • How would you partition and shard the database to optimize both real-time store-level queue queries and customer global order-history lookups?