State management (idle, moving up, moving down) in LLD - System Design Exercise

Design: Elevator State Management System

Design focuses on the state management logic and transitions for a single elevator. Hardware control and multi-elevator coordination are out of scope.

Functional Requirements

FR1: Track elevator states: idle, moving up, moving down

FR2: Allow state transitions based on commands and current state

FR3: Handle requests to move elevator up or down

FR4: Prevent invalid state transitions (e.g., moving up when already moving up)

FR5: Provide current state information on demand

Non-Functional Requirements

NFR1: System should respond to state change requests within 100ms

NFR2: Support up to 100 concurrent elevator state requests

NFR3: Ensure state consistency at all times

NFR4: System availability target: 99.9% uptime

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

State machine to manage elevator states

Command handler to process move requests

State storage to keep current state

Event logger for state transitions

API or interface to query current state

Design Patterns

Finite State Machine (FSM) pattern

Observer pattern for state change notifications

Command pattern for encapsulating requests

Singleton pattern for centralized state management

Reference Architecture

 +---------------------+
 | Elevator Controller |
 +----------+----------+
            |
            v
 +---------------------+
 |   State Machine      |
 | (Idle, Moving Up,    |
 |  Moving Down)        |
 +----------+----------+
            |
            v
 +---------------------+
 | State Storage       |
 +---------------------+
            |
            v
 +---------------------+
 | Event Logger        |
 +---------------------+

Components

Elevator Controller

Custom logic module

Receives commands and interacts with the state machine

State Machine

Finite State Machine implementation

Manages elevator states and valid transitions

State Storage

In-memory store or lightweight database

Stores current elevator state persistently

Event Logger

Logging system

Records state changes for auditing and debugging

Request Flow

1. User sends a move up or move down command to Elevator Controller.

2. Elevator Controller forwards the command to the State Machine.

3. State Machine checks current state and validates transition.

4. If valid, State Machine updates the state to moving up or moving down.

5. State Storage is updated with the new state.

6. Event Logger records the state transition event.

7. Elevator Controller confirms the state change back to the user.

8. When movement completes, a command to set state to idle is processed similarly.

Database Schema

Entity: ElevatorState - id (primary key) - current_state (enum: idle, moving_up, moving_down) - last_updated_timestamp No complex relationships needed as this is a single entity tracking current state.

Scaling Discussion

Bottlenecks

High frequency of state change requests causing race conditions

State storage becoming a single point of failure

Event Logger performance degradation with large logs

Handling multiple elevators with isolated states

Solutions

Implement locking or atomic operations in state machine to prevent race conditions

Use distributed cache or replicated storage for state persistence

Archive old logs and use asynchronous logging to improve performance

Extend design to support multiple elevator instances with separate state machines

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying assumptions, 20 minutes designing the state machine and components, 10 minutes discussing scaling and edge cases, 5 minutes summarizing.

Explain the importance of clear state definitions and valid transitions

Describe how the finite state machine ensures consistency

Discuss how to handle concurrent requests safely

Mention persistence and logging for reliability and debugging

Outline scaling strategies for multiple elevators or high request volumes

Practice

1. What is the main purpose of state management in a system with states like idle, moving up, and moving down?

easy

A. To track and control what the system is doing at any moment

B. To store user data permanently

C. To speed up the system hardware

D. To create random outputs

Solution

1. Step 1: Understand the role of state management

   State management keeps track of the current condition or mode of the system, such as idle or moving.

2. Step 2: Identify the purpose in context

   It helps control system behavior by knowing what action to take based on the current state.

3. Final Answer:

   To track and control what the system is doing at any moment -> Option A

4. Quick Check:

   State management = track system state [OK]

Hint: State management controls system actions by tracking current state [OK]

Common Mistakes:

• Confusing state management with data storage
• Thinking it improves hardware speed
• Assuming it generates outputs randomly

2. Which of the following is the correct way to represent the state transitions for a system with states idle, moving up, and moving down?

easy

A. moving down -> moving up -> idle only

B. idle -> moving up -> moving down -> idle

C. moving up -> moving down -> idle only

D. idle -> moving up, idle -> moving down, moving up -> idle, moving down -> idle

Solution

1. Step 1: Identify valid transitions between states

   The system can start idle, then move up or down, and return to idle after movement.

2. Step 2: Check which option lists all valid transitions

   idle -> moving up, idle -> moving down, moving up -> idle, moving down -> idle correctly lists transitions from idle to moving states and back to idle.

3. Final Answer:

   idle -> moving up, idle -> moving down, moving up -> idle, moving down -> idle -> Option D

4. Quick Check:

   Valid transitions include idle to moving and back [OK]

Hint: State transitions must include all valid moves between states [OK]

Common Mistakes:

• Assuming linear transitions only
• Missing transitions back to idle
• Ignoring that moving up and down are separate states

3. Given the following pseudo-code for state transitions, what will be the final state after these events: start at idle, move up, move down, idle?

state = 'idle'
if event == 'move up' and state == 'idle':
    state = 'moving up'
elif event == 'move down' and state == 'idle':
    state = 'moving down'
elif event == 'stop' and state in ['moving up', 'moving down']:
    state = 'idle'

medium

A. error

B. moving down

C. moving up

D. idle

Solution

1. Step 1: Trace the events and state changes

   Start: state = 'idle'
   Event 'move up': matches first if, state = 'moving up'
   Event 'move down': does not match any condition (state != 'idle', event != 'stop'), no change
   Event 'idle': does not match any condition, no change. Final state = 'moving up'

2. Step 2: Determine final state

   After all events, the state is 'moving up'.

3. Final Answer:

   moving up -> Option C

4. Quick Check:

   Trace confirms final state 'moving up' [OK]

Hint: Follow events step-by-step to track state changes [OK]

Common Mistakes:

• Assuming move down changes state from moving up
• Thinking event 'idle' triggers return to idle
• Confusing event names with states

4. Identify the error in this state transition logic for a system with states idle, moving up, and moving down:

if state == 'idle' and event == 'move up':
    state = 'moving up'
elif state == 'moving up' and event == 'move down':
    state = 'moving down'
elif state == 'moving down' and event == 'stop':
    state = 'idle'

medium

A. Missing transition from idle to moving down

B. Missing transition from idle to moving up

C. Incorrect event name for stopping

D. State variable is not updated

Solution

1. Step 1: Review all possible transitions

   The code allows idle to moving up, moving up to moving down, and moving down to idle, but no direct transition from idle to moving down.

2. Step 2: Identify missing transitions

   Since the system should allow moving down from idle, this transition is missing.

3. Final Answer:

   Missing transition from idle to moving down -> Option A

4. Quick Check:

   Check all valid transitions included [OK]

Hint: Check if all state-event pairs have transitions [OK]

Common Mistakes:

• Assuming moving up can switch directly to moving down
• Ignoring missing transitions from idle
• Confusing event names with states

5. You are designing a state machine for an elevator with states idle, moving up, and moving down. Which design choice best ensures scalability and clear control flow when adding more states like door open or maintenance?

hard

A. Hardcode state changes inside each function without a state map

B. Use a centralized state manager with explicit allowed transitions and event handlers

C. Use global variables and if-else checks scattered across code

D. Ignore state management and rely on random delays

Solution

1. Step 1: Consider scalability and clarity

   A centralized state manager clearly defines states and allowed transitions, making it easier to add new states and maintain control flow.

2. Step 2: Evaluate other options

   Using global variables or hardcoding state changes leads to messy, error-prone code. Ignoring state management causes unpredictable behavior.

3. Final Answer:

   Use a centralized state manager with explicit allowed transitions and event handlers -> Option B

4. Quick Check:

   Centralized state management = scalable and clear [OK]

Hint: Centralize state logic for easier scaling and maintenance [OK]

Common Mistakes:

• Scattering state logic causing bugs
• Hardcoding states making changes hard
• Ignoring state management leads to chaos