State diagrams in LLD - System Design Exercise

Design: State Diagram Design for a Simple Order Processing System

Design the state diagram and explain transitions for order processing only. Implementation details and UI design are out of scope.

Functional Requirements

FR1: Model the states of an order from creation to completion

FR2: Include states: Created, Paid, Shipped, Delivered, Cancelled

FR3: Allow transitions only in logical order (e.g., cannot ship before payment)

FR4: Support cancellation from certain states

FR5: Visualize state transitions clearly

Non-Functional Requirements

NFR1: Diagram must be easy to understand for non-technical stakeholders

NFR2: Must accurately represent all valid state transitions

NFR3: Should be scalable to add more states in future

NFR4: Use industry standard notation for state diagrams

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

States (nodes) representing order statuses

Transitions (arrows) showing allowed moves between states

Start and end states

Guards or conditions on transitions if needed

Annotations for clarity

Design Patterns

Finite State Machine (FSM) pattern

Hierarchical state machines for complex states

Event-driven transitions

Use of entry/exit actions in states

Reference Architecture

Start

↓

End

Components

States

UML State Diagram notation

Represent different statuses of an order

Transitions

Directed arrows in UML

Show allowed moves between states triggered by events

Start and End States

Special UML notation (filled circle for start, bullseye for end)

Mark beginning and completion of order lifecycle

Request Flow

1. User creates an order -> system sets state to Created

2. User pays for order -> transition from Created to Paid

3. Order is shipped -> transition from Paid to Shipped

4. Order is delivered -> transition from Shipped to Delivered

5. User can cancel order from Created or Paid states -> transition to Cancelled

6. Once Delivered or Cancelled, order lifecycle ends

Database Schema

Entities: - Order: id, current_state (Created, Paid, Shipped, Delivered, Cancelled), timestamps Relationships: - None needed specifically for state diagram, but order state stored as attribute

Scaling Discussion

Bottlenecks

Diagram complexity grows with more states and transitions

Hard to maintain and understand if states become too many

Lack of modularity for complex workflows

Solutions

Use hierarchical state machines to group related states

Modularize diagrams by splitting into sub-diagrams

Use tools that support zoom and layers for clarity

Add clear documentation and naming conventions

Interview Tips

Time: Spend 10 minutes clarifying requirements and states, 15 minutes drawing and explaining the diagram, 5 minutes discussing scaling and improvements, 15 minutes for questions

Explain why state diagrams help visualize system behavior

Describe each state and valid transitions clearly

Mention how invalid transitions are prevented

Discuss how the design can evolve with more states

Highlight use of standard UML notation for clarity