Why elevator design tests state machines in LLD - Scalability Evidence

Scalability Analysis - Why elevator design tests state machines

Growth Table: Elevator System Scaling

Users (People)	Elevator Requests per Minute	State Transitions per Second	System Complexity	Response Time Expectation
100	~10	~1	Simple: Few floors, few requests	Fast, near instant
10,000	~1,000	~100	Moderate: Multiple elevators, more floors	Still fast, some queuing
1,000,000	~100,000	~10,000	Complex: Many elevators, high concurrency	Needs optimized scheduling
100,000,000	~10,000,000	~1,000,000	Very complex: Large buildings, multiple zones	Requires distributed control

First Bottleneck: State Machine Complexity and Coordination

As the number of users and elevator requests grow, the elevator control system's state machine becomes the first bottleneck. This is because each elevator must track its current state (moving up, down, idle, door open/close) and respond to new requests correctly.

With many elevators and requests, the state machine logic and coordination between elevators become complex. Without efficient state management, the system can slow down, causing delays and incorrect behavior.

Scaling Solutions for Elevator State Machines

• Modular State Machines: Break down the elevator control into smaller, manageable state machines per elevator to reduce complexity.
• Hierarchical Control: Use a higher-level controller to coordinate multiple elevators, reducing state conflicts.
• Event-Driven Architecture: Use asynchronous events to handle state transitions efficiently.
• Load Balancing: Distribute requests evenly among elevators to avoid overloading one state machine.
• Simulation and Testing: Use automated tests to verify state transitions under heavy load.

Back-of-Envelope Cost Analysis

• At 1,000 requests per second, each elevator state machine must handle ~10-100 state transitions per second.
• CPU usage grows with the number of elevators and requests; a single server can handle ~1,000 concurrent state machines efficiently.
• Memory usage depends on storing states and queues; typically a few MBs per elevator.
• Network bandwidth is minimal as state machines mostly run locally; coordination messages are small.

Interview Tip: Structuring Scalability Discussion

Start by explaining what a state machine is and why elevators need them to track states.

Discuss how increasing users and requests increase state transitions and complexity.

Identify the first bottleneck as state machine coordination and complexity.

Propose clear scaling solutions like modular design, hierarchical control, and event-driven handling.

Use simple analogies like traffic lights or turnstiles to explain state machines.

Self Check Question

Your elevator control system handles 100 state transitions per second. Traffic grows 10x. What do you do first?

Answer: Break the monolithic state machine into smaller, modular state machines per elevator and introduce a higher-level coordinator to distribute requests. This reduces complexity and improves scalability.

Key Result

Elevator design tests state machines because as user requests grow, the complexity of managing elevator states and coordination becomes the first bottleneck. Modular and hierarchical state machine designs help scale efficiently.