Order tracking state machine in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identify the correct next state in an order tracking state machine

An order tracking system has the following states: Placed, Confirmed, Shipped, Delivered, and Cancelled. Which state should the order transition to immediately after Placed?

A Confirmed

B Shipped

C Delivered

D Cancelled

💡 Hint

Think about the logical flow of order processing after a customer places an order.

After an order is placed, it must be confirmed by the system or seller before shipping. So, the next state after Placed is Confirmed.

❓ Architecture

intermediate

Choose the best component to handle order state transitions

In designing an order tracking system, which component is best suited to manage the state transitions of orders reliably?

A A stateless REST API endpoint

B A state machine service with persistent storage

C A client-side JavaScript function

D A simple database table without logic

💡 Hint

Consider where state and logic should be maintained to ensure consistency and reliability.

A state machine service with persistent storage ensures that order states and transitions are managed reliably and consistently, even across failures.

❓ scaling

advanced

Scaling order state updates under high load

Your order tracking system must handle thousands of state updates per second during peak sales. Which approach best supports scaling these state transitions?

A Partition orders by region and use distributed state machines per partition

B Process all state transitions synchronously in a single service instance

C Use a single centralized database with strong locking for state updates

D Store states only in cache without persistence

💡 Hint

Think about how to distribute load and avoid bottlenecks.

Partitioning orders by region and using distributed state machines allows parallel processing and reduces contention, enabling better scalability.

❓ tradeoff

advanced

Tradeoff between consistency and availability in order state updates

In a distributed order tracking system, choosing between strong consistency and high availability for state updates is a key tradeoff. Which statement best describes this tradeoff?

A Choosing availability means the system never loses data even if nodes disagree on state

B Consistency and availability can always be achieved together without tradeoffs

C High availability means all nodes always have the latest state with zero delay

D Strong consistency guarantees all nodes see the same state immediately but may reduce availability during network issues

💡 Hint

Recall the CAP theorem and its implications for distributed systems.

Strong consistency ensures all nodes agree on the state immediately but can reduce availability if network partitions occur. This is a classic CAP theorem tradeoff.

❓ estimation

expert

Estimate storage requirements for order state history

Your system tracks the full state history of each order. Each state change record is 200 bytes. You expect 1 million orders per day, each with an average of 5 state changes. Estimate the storage needed for one month (30 days) of state history.

A 3 trillion bytes (3 TB)

B 300 billion bytes (300 GB)

C 30 billion bytes (30 GB)

D 30 trillion bytes (30 TB)

💡 Hint

Calculate total records and multiply by record size, then convert bytes to GB.

1 million orders/day * 5 changes = 5 million records/day. Over 30 days = 150 million records. 150 million * 200 bytes = 30 billion bytes = 30 GB (A).

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