Order state machine in LLD - System Design Exercise

Design: Order State Machine

Design focuses on the order state machine logic, APIs for state transitions and queries, concurrency control, and audit logging. Does not cover payment processing, shipping logistics, or UI design.

Functional Requirements

FR1: Support order lifecycle states: Created, Paid, Shipped, Delivered, Cancelled, Returned

FR2: Allow valid state transitions only (e.g., Created -> Paid, Paid -> Shipped)

FR3: Reject invalid transitions (e.g., Delivered -> Paid)

FR4: Provide ability to query current state of an order

FR5: Support concurrent updates safely to prevent invalid state changes

FR6: Log state changes for audit and debugging

FR7: Handle up to 1000 state transitions per second

Non-Functional Requirements

NFR1: Latency for state transition API should be under 100ms p99

NFR2: Availability target 99.9% uptime

NFR3: System must be scalable to handle 10,000 concurrent orders

NFR4: State transitions must be consistent and atomic

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

State machine engine enforcing transitions

Order state database

API layer for state change requests and queries

Concurrency control mechanism (e.g., optimistic locking)

Audit log storage

Cache for fast state queries

Design Patterns

State machine pattern

Event sourcing for audit logs

Optimistic concurrency control

Command Query Responsibility Segregation (CQRS)

Retry and idempotency for state change requests

Reference Architecture

          +----------------+
          |  Client/API    |
          +-------+--------+
                  |
                  v
          +-------+--------+          +----------------+
          | State Machine  | <------> | Order Database |
          | Engine        |          +----------------+
          +-------+--------+
                  |
                  v
          +-------+--------+
          | Audit Log Store|
          +----------------+

Components

State Machine Engine

Custom logic module

Enforces valid order state transitions and handles concurrency

Order Database

Relational DB (e.g., PostgreSQL)

Stores current order states and metadata

API Layer

RESTful API server

Exposes endpoints for clients to request state changes and query order state

Audit Log Store

Append-only log storage (e.g., Kafka or DB table)

Records all state changes for audit and debugging

Cache

In-memory cache (e.g., Redis)

Speeds up frequent order state queries

Request Flow

1. Client sends state transition request to API layer

2. API layer validates request format and authentication

3. API layer calls State Machine Engine to process transition

4. State Machine Engine checks current state from Order Database

5. State Machine Engine verifies if requested transition is valid

6. If valid, State Machine Engine updates Order Database atomically with new state

7. State Machine Engine writes state change event to Audit Log Store

8. API layer returns success or failure response to client

9. For state queries, API layer first checks Cache, then falls back to Order Database

Database Schema

Entities: - Order: order_id (PK), current_state, updated_at - StateTransitionLog: log_id (PK), order_id (FK), from_state, to_state, timestamp Relationships: - One Order has many StateTransitionLog entries - current_state in Order reflects latest valid state

Scaling Discussion

Bottlenecks

Database write contention on orders with frequent state changes

Audit log storage growing large and slowing writes

API layer becoming overloaded with high request volume

Cache consistency with database state

Solutions

Use optimistic locking or version numbers to handle concurrent updates safely

Partition audit logs by order or time to scale storage and queries

Deploy API layer behind load balancer with horizontal scaling

Use cache invalidation or write-through caching to keep cache consistent

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing

Clearly define valid states and transitions

Explain concurrency control to prevent invalid transitions

Describe how audit logging supports debugging and compliance

Discuss trade-offs between consistency and availability

Show understanding of scaling bottlenecks and mitigation

Practice

1.

What is the main purpose of an Order State Machine in a system?

easy

A. To track and control the valid states an order can be in during its lifecycle

B. To store customer payment details securely

C. To calculate the total price of an order

D. To manage user login sessions

Solution

1. Step 1: Understand the role of state machines

   State machines define allowed states and transitions for an entity, ensuring valid progress.

2. Step 2: Apply to order lifecycle

   For orders, the state machine controls stages like 'Pending', 'Shipped', 'Delivered', preventing invalid jumps.

3. Final Answer:

   To track and control the valid states an order can be in during its lifecycle -> Option A

4. Quick Check:

   Order state machine = control order states [OK]

Hint: State machines control valid order stages only [OK]

Common Mistakes:

• Confusing state machine with payment processing
• Thinking it calculates prices
• Mixing with user session management

2.

Which of the following is the correct way to represent a state transition in an order state machine?

class OrderStateMachine:
    def __init__(self):
        self.state = 'Pending'

    def ship(self):
        # Transition from Pending to Shipped
        ?

easy

A. if self.state == 'Pending': self.state = 'Shipped' else: raise Exception('Invalid transition')

B. self.state == 'Shipped'

C. self.state = 'Pending' if self.state == 'Shipped' else 'Shipped'

D. self.ship = 'Shipped'

Solution

1. Step 1: Understand valid state change syntax

   Assign new state only if current state allows it; else raise error.

2. Step 2: Check each option

   if self.state == 'Pending': self.state = 'Shipped' else: raise Exception('Invalid transition') correctly assigns 'Shipped' if current is 'Pending', else raises exception.

3. Final Answer:

   if self.state == 'Pending': self.state = 'Shipped' else: raise Exception('Invalid transition') -> Option A

4. Quick Check:

   Valid transition check = if self.state == 'Pending': self.state = 'Shipped' else: raise Exception('Invalid transition') [OK]

Hint: Assign new state only if current state matches [OK]

Common Mistakes:

• Using comparison (==) instead of assignment (=)
• Assigning wrong state based on condition
• Changing method name instead of state

3.

Given the following code snippet for an order state machine, what will be the output after calling cancel() twice?

class OrderStateMachine:
    def __init__(self):
        self.state = 'Pending'

    def cancel(self):
        if self.state in ['Pending', 'Shipped']:
            self.state = 'Cancelled'
        else:
            print('Cannot cancel from', self.state)

order = OrderStateMachine()
order.cancel()
order.cancel()
print(order.state)

medium

A. Cancelled

B. Pending

C. Cannot cancel from Cancelled\nCancelled

D. Error

Solution

1. Step 1: Trace first cancel call

   Initial state is 'Pending', so state changes to 'Cancelled'.

2. Step 2: Trace second cancel call

   State is now 'Cancelled', so print message 'Cannot cancel from Cancelled' and state stays 'Cancelled'.

3. Final Answer:

   Cannot cancel from Cancelled\nCancelled -> Option C

4. Quick Check:

   Second cancel prints message, state remains Cancelled [OK]

Hint: Check state before transition; print if invalid [OK]

Common Mistakes:

• Assuming second cancel changes state again
• Ignoring printed message
• Expecting error instead of print

4.

Identify the bug in this order state machine method that allows invalid state transitions:

def deliver(self):
    if self.state == 'Shipped' or 'Out for Delivery':
        self.state = 'Delivered'
    else:
        raise Exception('Invalid transition');

medium

A. The method should use 'and' instead of 'or'

B. The method does not change the state

C. The exception message is missing

D. The condition always evaluates to True due to incorrect or usage

Solution

1. Step 1: Analyze the condition logic

   The condition uses 'if self.state == 'Shipped' or 'Out for Delivery'', which always evaluates True because non-empty strings are truthy.

2. Step 2: Correct the condition

   It should be 'if self.state == 'Shipped' or self.state == 'Out for Delivery'' to check both states properly.

3. Final Answer:

   The condition always evaluates to True due to incorrect or usage -> Option D

4. Quick Check:

   Incorrect or condition causes always True [OK]

Hint: Check boolean conditions carefully for correct comparisons [OK]

Common Mistakes:

• Using 'or' with string literals incorrectly
• Forgetting to compare both sides explicitly
• Assuming condition works as intended

5.

You are designing an order state machine for an online store. The order states are Pending, Confirmed, Shipped, Delivered, and Cancelled. Which design ensures scalability and prevents invalid transitions?

Choose the best approach:

1. Use a dictionary mapping each state to allowed next states.
2. Hardcode all transitions in if-else blocks.
3. Allow any state to transition to any other state.
4. Use a single variable without validation.

hard

A. Use a single variable without validation

B. Use a dictionary mapping each state to allowed next states

C. Allow any state to transition to any other state

D. Hardcode all transitions in if-else blocks

Solution

1. Step 1: Evaluate scalability and validation needs

   Hardcoding transitions is error-prone and hard to maintain; allowing any transition breaks rules.

2. Step 2: Choose dictionary mapping

   Mapping states to allowed next states centralizes rules, making it easy to update and validate transitions.

3. Final Answer:

   Use a dictionary mapping each state to allowed next states -> Option B

4. Quick Check:

   Dictionary mapping = scalable, validated transitions [OK]

Hint: Map states to allowed next states for clean validation [OK]

Common Mistakes:

• Hardcoding transitions everywhere
• Skipping validation of transitions
• Allowing invalid state jumps