Order tracking state machine in LLD - System Design Exercise

Design: Order Tracking State Machine

Design the state machine logic, API interface, and data model for order states. Out of scope: payment processing, inventory management.

Functional Requirements

FR1: Track the state of an order from placement to delivery

FR2: Support states: Created, Confirmed, Packed, Shipped, Out for Delivery, Delivered, Cancelled

FR3: Allow valid transitions only (e.g., cannot ship before packing)

FR4: Notify users on state changes

FR5: Handle concurrent updates safely

FR6: Provide API to query current order state

FR7: Support at least 10,000 orders concurrently

Non-Functional Requirements

NFR1: API response latency p99 < 100ms

NFR2: System availability 99.9%

NFR3: State transitions must be consistent and atomic

NFR4: Scalable to handle peak loads during sales events

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

State machine engine or library

Order state database

API server for client interaction

Notification service

Concurrency control mechanism

Design Patterns

State machine pattern

Event sourcing for state changes

Observer pattern for notifications

Optimistic locking for concurrency

RESTful API design

Reference Architecture

API Server

↓

Notification Service

Components

API Server

Node.js/Express or Python/Flask

Expose REST API endpoints for querying and updating order states

State Machine Logic

Custom code or state machine library

Enforce valid state transitions and business rules

Order State Database

Relational DB (PostgreSQL) or NoSQL (DynamoDB)

Persist order states and transition history

Notification Service

Message queue (RabbitMQ) + Email/SMS gateway

Send asynchronous notifications on state changes

Concurrency Control

Optimistic locking or transactions

Prevent conflicting state updates

Request Flow

1. Client sends API request to update order state

2. API Server receives request and forwards to State Machine Logic

3. State Machine Logic validates requested transition against current state

4. If valid, State Machine Logic updates Order State Database atomically

5. State Machine Logic triggers Notification Service asynchronously

6. API Server responds with updated order state

7. Client can query current order state via API

Database Schema

Entities: - Order: order_id (PK), current_state, user_id, timestamps - OrderStateHistory: id (PK), order_id (FK), previous_state, new_state, changed_at Relationships: - One Order has many OrderStateHistory records - current_state in Order reflects latest state - State transitions validated before updating current_state

Scaling Discussion

Bottlenecks

Database write contention on popular orders during peak times

Notification service overload with many state changes

API server CPU/memory limits under high concurrent requests

State machine logic becoming a single point of failure

Solutions

Use database sharding or partitioning by order_id to distribute load

Implement batching and rate limiting in Notification Service

Deploy API servers behind load balancer with autoscaling

Design State Machine Logic as stateless microservice instances with shared DB

Interview Tips

Time: 10 min for requirements and clarifications, 15 min for architecture and data model, 10 min for scaling and trade-offs, 10 min for Q&A

Clearly define states and allowed transitions

Explain concurrency control to maintain consistency

Discuss asynchronous notifications for better performance

Justify technology choices based on requirements

Highlight scalability strategies for peak loads

Practice

1. What is the main purpose of an Order Tracking State Machine in system design?

easy

A. To manage user authentication and sessions

B. To store customer payment information securely

C. To calculate the total price of an order

D. To represent the different stages an order goes through and control transitions

Solution

1. Step 1: Understand the role of state machines

   A state machine models states and transitions between them based on events.

2. Step 2: Apply to order tracking context

   In order tracking, it shows order stages like placed, shipped, delivered, and controls valid moves.

3. Final Answer:

   To represent the different stages an order goes through and control transitions -> Option D

4. Quick Check:

   State machine = stages and transitions [OK]

Hint: Think: states show progress steps, transitions move between them [OK]

Common Mistakes:

• Confusing state machine with data storage
• Mixing order calculation with state control
• Assuming it handles user login

2. Which of the following is the correct way to define a state transition in a state machine for order tracking?

easy

A. transition('delivered', 'placed', event='return_order')

B. transition('placed', 'shipped', event='ship_order')

C. transition('shipped', 'placed', event='cancel_order')

D. transition('cancelled', 'delivered', event='refund')

Solution

1. Step 1: Identify valid order flow transitions

   Orders move forward: placed -> shipped -> delivered; backward or invalid transitions are not typical.

2. Step 2: Check each option's direction and event

   transition('placed', 'shipped', event='ship_order') correctly moves from placed to shipped on ship_order event; others reverse or skip states incorrectly.

3. Final Answer:

   transition('placed', 'shipped', event='ship_order') -> Option B

4. Quick Check:

   Valid forward transition = transition('placed', 'shipped', event='ship_order') [OK]

Hint: Transitions should follow logical order flow forward [OK]

Common Mistakes:

• Defining backward transitions without valid reason
• Skipping intermediate states
• Using wrong event names

3. Given this simplified state machine code snippet:

state = 'placed'
event = 'ship_order'
if state == 'placed' and event == 'ship_order':
    state = 'shipped'
elif state == 'shipped' and event == 'deliver_order':
    state = 'delivered'
print(state)

What will be the output if event = 'deliver_order' when state = 'placed'?

medium

A. shipped

B. delivered

C. placed

D. error

Solution

1. Step 1: Check condition for event 'deliver_order' when state is 'placed'

   The first if checks for 'ship_order' event; it does not match 'deliver_order'. The elif checks for 'shipped' state, but current state is 'placed'.

2. Step 2: Determine state after conditions

   No condition matches, so state remains unchanged as 'placed'.

3. Final Answer:

   placed -> Option C

4. Quick Check:

   No matching transition keeps state same [OK]

Hint: If no condition matches, state stays unchanged [OK]

Common Mistakes:

• Assuming event triggers transition regardless of current state
• Confusing elif with else
• Expecting error without exception handling

4. Identify the bug in this order tracking state machine snippet:

state = 'shipped'
event = 'cancel_order'
if state == 'placed' and event == 'cancel_order':
    state = 'cancelled'
elif state == 'shipped' and event == 'cancel_order':
    print('Cannot cancel after shipping')
else:
    state = 'cancelled'
print(state)

medium

A. The else block cancels order even after shipping

B. Missing transition from 'placed' to 'shipped'

C. No print statement for cancellation confirmation

D. State variable is not updated correctly for 'placed' state

Solution

1. Step 1: Analyze conditions for state 'shipped' and event 'cancel_order'

   The if does not match. The elif matches, prints 'Cannot cancel after shipping' but leaves state unchanged. However, if event were different (e.g., 'deliver_order') with state='shipped', if and elif fail, else wrongly sets state='cancelled'.

2. Step 2: Identify why this is a bug

   The else acts as a catch-all, allowing cancellation of shipped orders for unhandled events, contradicting the intent to prevent cancellation after shipping.

3. Final Answer:

   The else block cancels order even after shipping -> Option A

4. Quick Check:

   Else wrongly cancels unhandled shipped cases [OK]

Hint: Else block can override specific conditions--check carefully [OK]

Common Mistakes:

• Ignoring else block effects
• Assuming print prevents state change
• Not testing all branches

5. You need to design an order tracking state machine that handles normal flow and exceptions like cancellation and returns. Which design approach best ensures scalability and clarity?

hard

A. Model states hierarchically with sub-states for exceptions and normal flow

B. Use a single flat state list with many transitions for all cases

C. Handle exceptions outside the state machine with separate logic

D. Use only two states: 'active' and 'closed' to simplify design

Solution

1. Step 1: Understand complexity of order states

   Orders have normal states (placed, shipped, delivered) and exceptions (cancelled, returned) which can be grouped logically.

2. Step 2: Evaluate design approaches for scalability and clarity

   Hierarchical states allow grouping related states, reducing complexity and improving maintainability compared to flat or oversimplified models.

3. Final Answer:

   Model states hierarchically with sub-states for exceptions and normal flow -> Option A

4. Quick Check:

   Hierarchical states = scalable and clear [OK]

Hint: Group related states hierarchically for clarity and scale [OK]

Common Mistakes:

• Using flat states causing many transitions
• Ignoring exceptions in state machine
• Oversimplifying states losing detail