Order tracking state machine in LLD - System Design Guide

Problem Statement

When an order moves through multiple stages like placement, payment, shipping, and delivery, tracking its current state can become confusing and error-prone. Without a clear system, the order might jump to invalid states or miss important transitions, causing customer frustration and operational mistakes.

Solution

A state machine defines all valid states an order can be in and the allowed transitions between them. It enforces rules so the order can only move from one valid state to another, preventing invalid changes. This makes tracking order progress reliable and easier to manage.

Architecture

Placed

↓

Cancelled

This diagram shows the order states as boxes and arrows as allowed transitions between states.

Trade-offs

✓ Pros

→

Prevents invalid order state transitions, reducing bugs.

→

Makes order flow explicit and easier to understand.

→

Simplifies debugging by knowing exactly which states are possible.

→

Facilitates adding new states or transitions in a controlled way.

✗ Cons

→

Adds complexity to simple order flows with few states.

→

Requires upfront design and maintenance of state rules.

→

Can be rigid if business processes change frequently.

Use when order processing involves multiple distinct stages and transitions, especially if state validation or complex flows are needed. Suitable for systems handling thousands of orders daily.

Avoid if order processing is very simple with only one or two states, or if the system is a prototype where flexibility is more important than strict state control.

Real World Examples

Amazon

Amazon uses order state machines to track orders from placement through payment, packaging, shipping, and delivery, ensuring customers see accurate status updates.

Uber Eats

Uber Eats tracks food orders through states like placed, accepted by restaurant, prepared, picked up by driver, and delivered, preventing invalid status updates.

Shopify

Shopify implements order state machines to manage order lifecycle events and trigger notifications or actions at each valid state transition.

Code Example

The before code allows any status update, risking invalid states. The after code defines allowed transitions and raises an error if an invalid move is attempted, enforcing correct order state flow.

LLD

### Before: No state machine, just free status updates
class Order:
    def __init__(self):
        self.status = 'placed'

    def update_status(self, new_status):
        self.status = new_status


### After: Using a state machine to enforce valid transitions
class OrderStateMachine:
    allowed_transitions = {
        'placed': ['paid', 'cancelled'],
        'paid': ['shipped', 'cancelled'],
        'shipped': ['delivered'],
        'delivered': [],
        'cancelled': []
    }

    def __init__(self):
        self.state = 'placed'

    def transition(self, new_state):
        if new_state in self.allowed_transitions[self.state]:
            self.state = new_state
        else:
            raise ValueError(f"Invalid transition from {self.state} to {new_state}")


# Usage
order = OrderStateMachine()
order.transition('paid')  # valid
order.transition('shipped')  # valid
# order.transition('placed')  # raises error

Alternatives

Event-driven architecture

Instead of enforcing strict states, the system reacts to events and updates order status accordingly without a fixed state model.

Use when: Choose when order flows are highly dynamic or when integrating many external systems that emit events asynchronously.

Simple status flags

Use a single status field updated freely without enforced transitions.

Use when: Choose when order processing is very simple and strict state validation is not required.

Summary

Order tracking state machines prevent invalid state changes by defining allowed transitions.

They make order flows explicit and easier to maintain or extend.

They are best used when order processing involves multiple stages and strict validation is needed.

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