Order state machine in LLD - System Design Guide

Problem Statement

Without a clear control of order states, systems can process orders incorrectly, causing issues like shipping canceled orders or accepting payments for already delivered items. This leads to inconsistent order handling, customer dissatisfaction, and operational errors.

Solution

An order state machine enforces valid transitions between order states by defining allowed moves explicitly. It ensures the order progresses through states like 'Created', 'Paid', 'Shipped', and 'Delivered' in a controlled manner, preventing invalid or out-of-sequence actions.

Architecture

Created

→Paid

↓

Canceled

This diagram shows the allowed states of an order and the valid transitions between them, including payment, shipping, delivery, cancellation, and return.

Trade-offs

✓ Pros

→

Prevents invalid order state transitions, reducing errors.

→

Makes order processing logic explicit and easier to maintain.

→

Improves system reliability by enforcing business rules.

→

Facilitates debugging by clearly showing allowed state flows.

✗ Cons

→

Adds complexity to the order processing codebase.

→

Requires careful design to cover all valid transitions.

→

May need updates when business rules change, increasing maintenance.

Use when order processing involves multiple states with strict rules, especially in e-commerce systems handling thousands of orders daily.

Avoid if the order lifecycle is very simple (e.g., only 'Created' and 'Completed') or if the system handles fewer than 100 orders per day where manual checks suffice.

Real World Examples

Amazon

Amazon uses order state machines to ensure orders move correctly from placement to delivery, preventing shipping of canceled or unpaid orders.

Uber Eats

Uber Eats applies state machines to track food order statuses like 'Order Placed', 'Preparing', 'Picked Up', and 'Delivered' to coordinate between restaurants and drivers.

Shopify

Shopify implements order state machines to manage order fulfillment stages and handle returns or cancellations systematically.

Code Example

The before code allows changing order states without checks, risking invalid flows. The after code defines allowed transitions and enforces them, preventing invalid state changes and making order processing safer and clearer.

LLD

### Before: No state machine, direct state changes without checks
class Order:
    def __init__(self):
        self.state = 'Created'

    def pay(self):
        self.state = 'Paid'

    def ship(self):
        self.state = 'Shipped'

    def deliver(self):
        self.state = 'Delivered'

### After: Using state machine to enforce valid transitions
class OrderStateMachine:
    allowed_transitions = {
        'Created': ['Paid', 'Canceled'],
        'Paid': ['Shipped', 'Canceled'],
        'Shipped': ['Delivered', 'Canceled'],
        'Delivered': ['Returned'],
        'Canceled': [],
        'Returned': []
    }

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

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

    def pay(self):
        self.transition('Paid')

    def ship(self):
        self.transition('Shipped')

    def deliver(self):
        self.transition('Delivered')

    def cancel(self):
        self.transition('Canceled')

    def return_order(self):
        self.transition('Returned')

Alternatives

Event-driven architecture

Uses events to trigger state changes asynchronously rather than enforcing strict state transitions in a single flow.

Use when: Choose when you need high scalability and loose coupling between order processing components.

Workflow engine

Uses a configurable engine to define and execute order workflows, allowing dynamic changes without code updates.

Use when: Choose when business rules change frequently and non-developers need to modify order flows.

Summary

Order state machines prevent invalid order processing by enforcing allowed state transitions.

They make order flows explicit and easier to maintain, reducing operational errors.

They are best used in systems with multiple order states and strict business rules.

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