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

Practice

1. What is the main purpose of a state diagram in system design?

easy

A. To display the database schema and relationships

B. To list all the classes and their methods in a system

C. To show different states of a system and how it moves between them

D. To outline the network topology of system components

Solution

1. Step 1: Understand what a state diagram represents

   A state diagram shows the various states a system or component can be in and the transitions triggered by events.

2. Step 2: Compare with other diagrams

   Class diagrams show classes and methods, database diagrams show data structure, and network diagrams show connections, not states.

3. Final Answer:

   To show different states of a system and how it moves between them -> Option C

4. Quick Check:

   State diagram = system states and transitions [OK]

Hint: State diagrams focus on states and transitions only [OK]

Common Mistakes:

• Confusing state diagrams with class diagrams
• Thinking state diagrams show data structure
• Assuming state diagrams show network layout

2. Which of the following is the correct syntax to represent a transition from state A to state B on event start in a state diagram?

easy

A. A => start => B

B. A -> B : start

C. A --start--> B

D. A -start-> B

Solution

1. Step 1: Recall standard state diagram notation

   Transitions are usually shown as arrows with the event label after a colon, like A -> B : event.

2. Step 2: Match options with notation

   A -> B : start matches this format exactly. Others use incorrect symbols or order.

3. Final Answer:

   A -> B : start -> Option B

4. Quick Check:

   Transition syntax = A -> B : event [OK]

Hint: Use arrow then colon for event label in transitions [OK]

Common Mistakes:

• Using double dashes instead of single arrow
• Placing event before arrow
• Omitting colon before event label

3. Given the following state diagram code snippet:

Idle -> Processing : start
Processing -> Idle : stop
Processing -> Error : fail

What is the next state if the system is in Processing and receives the fail event?

medium

A. Error

B. Idle

C. Processing

D. Start

Solution

1. Step 1: Identify current state and event

   The system is in Processing state and receives fail event.

2. Step 2: Find matching transition

   From Processing, on fail, the transition goes to Error.

3. Final Answer:

   Error -> Option A

4. Quick Check:

   Processing + fail = Error [OK]

Hint: Match current state and event to transition target [OK]

Common Mistakes:

• Choosing Idle instead of Error
• Confusing event names
• Ignoring event and state pairing

4. Identify the error in this state diagram transition:

Start -> Running : begin
Running -> Paused : pause
Paused -> Running pause

What is wrong with the last transition?

medium

A. Missing colon before event name

B. Wrong arrow direction

C. State name misspelled

D. Extra event name

Solution

1. Step 1: Review transition syntax

   Transitions should have a colon before the event name, e.g., State1 -> State2 : event.

2. Step 2: Check last transition

   The last line is Paused -> Running pause missing the colon before pause.

3. Final Answer:

   Missing colon before event name -> Option A

4. Quick Check:

   Colon before event is required [OK]

Hint: Check for colon before event label in transitions [OK]

Common Mistakes:

• Ignoring missing colon
• Assuming arrow direction is wrong
• Thinking state name is incorrect

5. You are designing a state diagram for a vending machine with states: Idle, Selecting, Dispensing, and OutOfStock. Which transition should be added to handle the event stockEmpty when the machine is in Idle?

hard

A. Dispensing -> OutOfStock : stockEmpty

B. Idle -> Dispensing : stockEmpty

C. OutOfStock -> Idle : stockEmpty

D. Idle -> OutOfStock : stockEmpty

Solution

1. Step 1: Understand event context

   The event stockEmpty means no items are left to dispense.

2. Step 2: Determine correct transition from Idle

   If the machine is Idle and stock is empty, it should move to OutOfStock state.

3. Final Answer:

   Idle -> OutOfStock : stockEmpty -> Option D

4. Quick Check:

   stockEmpty from Idle leads to OutOfStock [OK]

Hint: Event triggers transition to correct state logically [OK]

Common Mistakes:

• Transitioning to Dispensing when stock is empty
• Reversing transition direction
• Ignoring event meaning