Why elevator design tests state machines in LLD - Design It to Understand It

Design: Elevator Control System

Design the elevator control logic focusing on state transitions and request handling. Out of scope: physical elevator mechanics and hardware details.

Functional Requirements

FR1: Manage elevator movements between floors

FR2: Handle multiple requests from different floors and inside the elevator

FR3: Ensure safe and efficient operation

FR4: Respond correctly to door open/close commands

FR5: Handle emergency stop and maintenance modes

Non-Functional Requirements

NFR1: System must respond to requests within 200ms

NFR2: Support up to 10 floors and 4 elevators

NFR3: Ensure 99.9% uptime for elevator control

NFR4: Must prevent conflicting commands that cause unsafe states

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

State machine to represent elevator states

Request queue management

Event handler for button presses and sensors

Safety and emergency modules

Design Patterns

Finite State Machine (FSM)

Event-driven architecture

Command pattern for request handling

Observer pattern for sensor updates

Reference Architecture

  +---------------------+
  | Elevator Controller |
  +----------+----------+
             |
   +---------v---------+
   |   State Machine   |
   +---------+---------+
             |
   +---------v---------+
   | Request Queue     |
   +---------+---------+
             |
   +---------v---------+
   | Motor & Door Ctrl |
   +-------------------+

Components

Elevator Controller

Custom logic module

Coordinates elevator operations and manages state transitions

State Machine

Finite State Machine implementation

Represents elevator states like Idle, MovingUp, MovingDown, DoorOpen, DoorClosed, Emergency

Request Queue

Priority queue data structure

Stores and prioritizes floor requests from users

Motor & Door Control

Hardware interface module

Executes commands to move elevator and open/close doors

Request Flow

1. User presses floor button inside elevator or on a floor panel

2. Request is sent to Elevator Controller

3. Controller adds request to Request Queue

4. State Machine checks current state and decides next action

5. If idle, State Machine transitions to MovingUp or MovingDown based on request

6. Motor & Door Control receives commands to move elevator or open/close doors

7. Sensors update State Machine on arrival at floors or door status

8. State Machine transitions to DoorOpen state to allow passenger movement

9. After door closes, State Machine checks for next request or returns to Idle

10. Emergency or maintenance events trigger special states to halt operations safely

Database Schema

Entities: - Elevator: id, current_floor, current_state - Request: id, floor_number, direction, timestamp - State: name, allowed_transitions Relationships: - Elevator has many Requests - State defines allowed transitions for Elevator states

Scaling Discussion

Bottlenecks

Handling many simultaneous requests causing queue congestion

State machine complexity increasing with more floors and elevators

Latency in sensor updates affecting state accuracy

Ensuring safety under hardware failures or emergency conditions

Solutions

Implement request batching and prioritization to reduce queue size

Modularize state machine per elevator to reduce complexity

Use real-time sensor data streaming with fallback checks

Add redundant safety checks and fail-safe states in state machine

Interview Tips

Time: 10 minutes to clarify requirements and constraints, 20 minutes to design state machine and data flow, 10 minutes to discuss scaling and safety considerations, 5 minutes for questions

Explain why elevator behavior fits well with state machines

Describe key states and transitions clearly

Show how requests are managed and prioritized

Highlight safety and emergency handling in design

Discuss scaling challenges and practical solutions

Practice

1. Why is elevator design often used to test state machines in system design?

easy

A. Because elevators have clear states and transitions that model real-world behavior

B. Because elevators require complex database management

C. Because elevators use machine learning algorithms

D. Because elevators operate without any state changes

Solution

1. Step 1: Understand elevator operation basics

   Elevators move between floors and have states like moving up, moving down, idle, door open, and door closed.

2. Step 2: Connect elevator states to state machine concept

   State machines model systems with defined states and transitions, matching elevator behavior perfectly.

3. Final Answer:

   Because elevators have clear states and transitions that model real-world behavior -> Option A

4. Quick Check:

   Elevator states = clear states and transitions [OK]

Hint: Elevators have clear states and transitions [OK]

Common Mistakes:

• Thinking elevators don't have states
• Confusing state machines with databases
• Assuming elevators use AI for basic movement

2. Which of the following correctly represents a state transition in an elevator state machine?

easy

A. Idle -> Door Open -> Moving Up

B. Idle -> Moving Up -> Door Open

C. Door Open -> Moving Down -> Door Closed

D. Moving Up -> Door Closed -> Idle

Solution

1. Step 1: Identify valid elevator state order

   An elevator usually goes from Idle to Moving Up, then Door Open when it reaches the floor.

2. Step 2: Check each option's sequence

   Idle -> Moving Up -> Door Open correctly shows Idle -> Moving Up -> Door Open, a valid transition sequence.

3. Final Answer:

   <code>Idle -> Moving Up -> Door Open</code> -> Option B

4. Quick Check:

   Idle to Moving Up to Door Open = valid transition [OK]

Hint: Elevator moves before doors open [OK]

Common Mistakes:

• Opening doors before moving
• Closing doors while idle
• Skipping moving state

3. Given this simplified elevator state machine code snippet, what is the final state after these events: callElevator(), arriveFloor(), openDoor()?

states = ['Idle', 'Moving', 'DoorOpen']
current_state = 'Idle'

def callElevator():
    global current_state
    if current_state == 'Idle':
        current_state = 'Moving'

def arriveFloor():
    global current_state
    if current_state == 'Moving':
        current_state = 'DoorOpen'

def openDoor():
    global current_state
    if current_state == 'DoorOpen':
        current_state = 'Idle'

medium

A. Idle

B. Moving

C. DoorOpen

D. Error

Solution

1. Step 1: Trace callElevator()

   Starting at 'Idle', callElevator() changes state to 'Moving'.

2. Step 2: Trace arriveFloor() and openDoor()

   arriveFloor() changes 'Moving' to 'DoorOpen', then openDoor() changes 'DoorOpen' back to 'Idle'.

3. Final Answer:

   Idle -> Option A

4. Quick Check:

   Idle after all events = Idle [OK]

Hint: Follow state changes step-by-step [OK]

Common Mistakes:

• Skipping openDoor() effect
• Assuming state stays at DoorOpen
• Confusing event order

4. In this elevator state machine code, what is the bug causing the elevator to never open doors?

current_state = 'Idle'

def callElevator():
    global current_state
    if current_state == 'Idle':
        current_state = 'Moving'

def arriveFloor():
    global current_state
    if current_state == 'Moving':
        current_state = 'Idle'  # Bug here

def openDoor():
    global current_state
    if current_state == 'DoorOpen':
        current_state = 'Idle'

medium

A. current_state is not initialized

B. callElevator() does not change state

C. openDoor() changes state incorrectly

D. arriveFloor() sets state to 'Idle' instead of 'DoorOpen'

Solution

1. Step 1: Analyze arriveFloor() function

   arriveFloor() changes 'Moving' state directly to 'Idle', skipping 'DoorOpen'.

2. Step 2: Understand effect on door opening

   Since state never becomes 'DoorOpen', openDoor() condition never triggers, so doors never open.

3. Final Answer:

   arriveFloor() sets state to 'Idle' instead of 'DoorOpen' -> Option D

4. Quick Check:

   arriveFloor() wrong state change = no door open [OK]

Hint: Check if all states are reachable in transitions [OK]

Common Mistakes:

• Ignoring wrong state assignment
• Assuming callElevator() is faulty
• Overlooking openDoor() condition

5. You are designing an elevator system with multiple elevators and floors. Why is modeling the system as a state machine important for safety and scalability?

hard

A. It eliminates the need for sensors and hardware checks

B. It allows elevators to learn user preferences automatically

C. It ensures predictable behavior and clear transitions, preventing unsafe states

D. It reduces the number of elevators needed by half

Solution

1. Step 1: Understand state machine benefits in complex systems

   State machines define clear states and transitions, making system behavior predictable and easier to manage.

2. Step 2: Connect predictability to safety and scalability

   Predictable transitions prevent unsafe states like doors opening while moving, and help scale by managing multiple elevators consistently.

3. Final Answer:

   It ensures predictable behavior and clear transitions, preventing unsafe states -> Option C

4. Quick Check:

   Predictable states = safety and scalability [OK]

Hint: Predictable states prevent unsafe elevator behavior [OK]

Common Mistakes:

• Confusing state machines with AI
• Ignoring safety in design
• Assuming hardware replaces software logic