OneNoughtOne
0/290
Loading content...
Read aloud is unavailable in this browser.
The elevator system is one of the most iconic Low-Level Design problems, and for good reason. It encapsulates multiple challenging aspects of real-time system design: state management, concurrent request handling, scheduling optimization, and hardware-software interface abstraction.
Unlike many LLD problems that focus primarily on data modeling, an elevator system demands that you think about temporal behavior—how the system evolves over time in response to continuous, unpredictable inputs. This makes it an exceptional vehicle for learning state machines, observer patterns, and strategy-based algorithm selection.
In this comprehensive case study, we will design a complete elevator control system from first principles, making deliberate design decisions and understanding the trade-offs at each step.
By completing this case study, you will be able to:
• Systematically gather and document requirements for real-time control systems • Design state machines that model complex, time-varying behavior • Select and implement appropriate scheduling algorithms with clear justification • Apply State, Strategy, and Observer patterns in a cohesive, production-grade design • Navigate trade-offs between simplicity, performance, and extensibility
Before writing any code or drawing any diagrams, a Principal Engineer approaches LLD problems by deeply understanding the problem domain. For elevator systems, this means understanding how real elevators operate, what physical constraints exist, and what user expectations define "good" behavior.
Physical Reality of Elevator Systems:
An elevator is a vertical transportation device that moves a car (or cab) along a shaft between floors. The system includes:
| Constraint | Physical Basis | Design Implication |
|---|---|---|
| Travel Time | Motors have limited acceleration/deceleration | Cannot instantly reach any floor; must model movement time |
| Direction Continuity | Reversing direction wastes energy and time | Efficient algorithms continue in one direction before reversing |
| Door Operations | Doors take ~3-5 seconds to open/close | Must model door state; affects availability for requests |
| Weight Capacity | Cars have maximum passenger/freight limits | May need to skip calls if at capacity |
| Single Shaft | One car per shaft (standard elevators) | Cannot pass another elevator; bank coordination needed |
Why These Constraints Matter:
Each physical constraint translates directly into software design decisions. For example, the fact that reversing direction is inefficient leads to the popular SCAN (elevator algorithm) scheduling approach. Understanding that door operations take time means our state machine must include door states, not just floor positions.
Ignoring these constraints leads to designs that are theoretically elegant but practically useless. A design where an elevator can "teleport" to any floor instantly might be simpler to code but teaches nothing about real system design.
In interviews and real-world design, demonstrating domain knowledge signals maturity. When designing an elevator system, mentioning constraints like "we should minimize direction reversals because each reversal wastes energy and increases mechanical wear" shows you think beyond the code.
Functional requirements define what the system must do. For an elevator system, these requirements fall into several categories based on the actors involved and the core use cases.
Primary Actors:
Core Use Cases:
Detailed Requirement Breakdown:
FR1 & FR2 — Request Handling:
These are the heart of the system. A hall call (floor request) includes the floor number and desired direction (up/down). A cab call (destination request) includes only the floor number since the passenger is already inside.
The system must:
FR3 — Door Operations:
Door behavior seems simple but has subtle requirements:
In an interview or initial design, explicitly state your scope. For example: "I'll design a system for a 20-floor building with 4 elevators. I'll handle standard passenger operations but defer weight sensors and voice announcements to extensions." This shows you can prioritize while acknowledging full scope.
Non-functional requirements (NFRs) define how well the system must perform its functions. For a real-time control system like an elevator, NFRs are often more challenging to achieve than functional requirements.
Why NFRs Are Critical for Elevators:
An elevator system that functionally works but has poor performance is unusable. Imagine an elevator that takes 2 minutes to respond to a button press, or one that can only handle 5 concurrent passengers in a 50-story building. The system would be correct but worthless.
| Category | Requirement | Target Metric | Rationale |
|---|---|---|---|
| Performance | Response Time | < 100ms for request acknowledgment | Instant feedback expected; long delays feel broken |
| Performance | Average Wait Time | < 30 seconds (low traffic), < 90 seconds (peak) | Industry standard for acceptable passenger experience |
| Reliability | System Uptime | 99.9% (excluding scheduled maintenance) | Building operations depend on elevator availability |
| Reliability | No Request Loss | Zero tolerance for lost requests | Passengers must never be stranded due to software bug |
| Safety | Emergency Response | < 5 seconds to halt on emergency | Critical for passenger safety |
| Safety | Graceful Degradation | Maintain service with N-1 elevators | Single elevator failure shouldn't cripple building |
| Scalability | Building Size | Support 1-100 floors, 1-20 elevators | Design should not hard-code building parameters |
| Maintainability | Code Modularity | Scheduling algorithm swappable | Different buildings need different optimization strategies |
Deep Dive: Average Wait Time Optimization
Average Wait Time (AWT) is the most scrutinized metric in elevator system design. It measures the time from when a passenger presses a hall call button to when an elevator arrives and opens its doors.
Factors affecting AWT:
A well-designed system targets:
In an interview or real-world design session, you must ask clarifying questions before diving into design. This demonstrates systematic thinking and ensures you don't solve the wrong problem. Here are the critical questions for an elevator system, organized by category.
Building Configuration Questions:
Behavioral Questions:
Technical Constraints:
After asking 3-5 critical questions, summarize your assumptions: "Based on our discussion, I'll design for a 20-floor office building with 4 standard elevators, all serving all floors. I'll focus on the control logic assuming hardware abstraction exists. We want to optimize for peak morning traffic (up-peak). Shall I proceed?" This confirms alignment and shows leadership.
With requirements gathered and questions answered, we must now draw clear boundaries around what we will design. Scope management is a critical skill—attempting to design everything results in designing nothing well.
The Concentric Circle Model of Scope:
Think of scope as three concentric circles:
| Scope Level | Included Components | Justification |
|---|---|---|
| Core | Elevator, Floor, Request, Controller entities | Essential for any elevator system |
| Core | State machine for elevator movement | Central to system behavior |
| Core | FCFS and SCAN scheduling algorithms | Demonstrates algorithm trade-offs |
| Core | Multi-elevator dispatch logic | Key differentiator in real systems |
| Extended | Weight sensor integration | Interface defined, implementation placeholder |
| Extended | Emergency mode handling | State acknowledged, simplified handling |
| Extended | Destination dispatch UI | Extension of request model |
| Out of Scope | Physical motor control | Hardware concern, not LLD |
| Out of Scope | Networking between floor panels | Infrastructure, not domain logic |
| Out of Scope | Voice announcements | Accessibility feature, orthogonal to core |
Our Design Assumptions:
For this case study, we will work with the following concrete parameters:
In interviews, candidates often fail by attempting to design too much. An interviewer would rather see a complete, well-reasoned design for a 4-elevator system than a half-baked design for a skyscraper with express zones, destination dispatch, fire modes, and voice AI. Constrain scope aggressively, then execute excellently.
To validate our requirements, we walk through specific scenarios. These serve as informal test cases for our design and help uncover edge cases.
Scenario 1: Simple Single-Passenger Journey
A passenger travels from floor 3 to floor 15
Passenger on floor 3 presses UP button, then selects floor 15 inside elevatorElevator arrives at floor 3, doors open, passenger enters, selects 15, doors close, elevator travels to 15, doors openExplanation
This scenario exercises: hall call registration, elevator dispatch, door operations, cab call registration, floor traversal, arrival detection. **Step-by-step flow:** 1. Passenger presses UP at floor 3 2. Controller receives hall call (floor=3, direction=UP) 3. Controller selects best elevator (e.g., Elevator A at floor 1, moving UP) 4. Elevator A adds floor 3 to its stop list 5. Elevator A arrives at floor 3, transitions to DOORS_OPENING 6. After door open duration, passenger enters 7. Passenger presses floor 15 button inside cab 8. System registers cab call (floor=15) 9. Doors close (DOORS_CLOSING → DOORS_CLOSED) 10. Elevator moves UP, passing floors 4-14 11. Elevator arrives at floor 15, opens doors 12. Passenger exits, hall call for floor 3 UP is satisfied
Scenario 2: Multiple Passengers, Path Optimization
Elevator handles multiple requests efficiently
Passengers waiting at floors 2, 5, and 8, all going UP. Elevator at floor 1.Elevator visits floors 2, 5, 8 in order (SCAN algorithm), picking up passengersExplanation
This demonstrates the SCAN algorithm advantage over FCFS. **SCAN (Elevator Algorithm):** 1. Elevator starts at floor 1, direction UP 2. Encounters request at floor 2 → stops, picks up 3. Continues UP, encounters request at floor 5 → stops 4. Continues UP, encounters request at floor 8 → stops 5. All passengers in-elevator now select destinations **Compare to FCFS (First-Come-First-Served):** If floor 8 requested first, FCFS would go: 1. Floor 1 → 8 (pick up) 2. Floor 8 → 2 (if called second) 3. Floor 2 → 5 (if called third) SCAN is clearly more efficient, avoiding unnecessary direction changes.
Scenario 3: Conflicting Directions
Elevator must decide how to handle opposite-direction requests
Elevator at floor 10 going UP. Floor 12 UP request. Floor 8 DOWN request.Elevator serves floor 12 first (same direction), then reverses to serve floor 8Explanation
Key insight: Continue in current direction until no more requests, then reverse. **Decision logic:** 1. Current: Floor 10, Direction UP 2. Pending requests: (12, UP), (8, DOWN) 3. SCAN continues UP → serves floor 12 first 4. After floor 12, no more UP requests above 12 5. Elevator reverses direction to DOWN 6. Now serves floor 8 DOWN request The floor 8 passenger sees a brief wait but avoids getting on an elevator going UP when they want DOWN.
Before proceeding to design, we validate that our requirements are complete, consistent, and feasible. This is a critical checkpoint that separates professional engineering from ad-hoc coding.
Open Questions for Future Iterations:
Even with thorough analysis, some questions remain open and should be documented:
These are flagged for future discovery, not blocking for initial design.
We have established a solid foundation: clear functional requirements, quantified non-functional requirements, explicit scope boundaries, and validated completeness. We're now ready to identify the core entities that will form our domain model.
Key Takeaways from Requirements Analysis:
What's Next:
With requirements firmly established, we proceed to entity identification and modeling. In the next page, we will:
This forms the static structure of our design, upon which we'll layer dynamic behavior (states, scheduling) in subsequent pages.
Notice how much work we invested before any code or UML diagrams. This is intentional. Requirements analysis typically represents 15-25% of design effort for experienced engineers. The investment pays dividends: clear requirements lead to clear entities, clear entities lead to clean code, and clean code leads to maintainable systems.