Design an Elevator System: Guide to System Design Interviews

When interviewers ask you to design an elevator system in a System Design interview, they aren’t looking to test whether you can actually build a real elevator. Instead, they want to see how you break down a real-world, complex system into manageable parts.

The elevator problem is popular because it combines:

• Object-Oriented Design (OOD): You need to think in terms of classes like Elevator, Controller, Button, and Request.
• System Design Thinking: You’ll deal with scheduling, concurrency, and scaling challenges.
• Practical Trade-Offs: Do you optimize for speed, fairness, or efficiency?

What makes this problem so effective for interviews is its balance. It’s complex enough to test your structured approach, but also familiar enough that you can reason about it without advanced domain knowledge.

By the end of this guide, you’ll know how to approach a System Design problem, like design an elevator system, step by step, covering everything from requirements to scalability and safety.

Problem Definition and Requirements Gathering

Before drawing diagrams or writing class definitions, you need to clarify requirements. This is where many candidates go wrong—they jump into coding without asking the right questions because they don’t know how to answer System Design interview questions.

Functional Requirements

These define what the system should do.

• Support multiple elevators in the same building.
• Allow users to request an elevator from any floor.
• Let passengers select destination floors once inside.
• Optimize elevator movement to minimize wait and travel time.
• Handle concurrent requests from multiple users.

Non-Functional Requirements

These define how the system should behave under constraints.

• Scalability: Should work for small buildings (5 floors) and skyscrapers (100+ floors).
• Reliability: Must operate even if one elevator breaks down.
• Safety: Emergency features like alarms, door sensors, and fail-safe stops.
• Performance: Average wait time should stay within acceptable limits.

Clarifying Questions to Ask in an Interview

• How many floors are we designing for?
• Should the system support multiple elevator banks?
• Are we optimizing for average wait time, fairness, or throughput?
• Do we need to support special modes like VIP or service elevators?

By framing these requirements upfront, you show the interviewer that you know how to design an elevator system that is grounded in user needs and real-world considerations.

High-Level Architecture of an Elevator System

Once requirements are clear, the next step is sketching out the high-level System Design. At its core, the system is about receiving requests and efficiently fulfilling them.

Core Components

• Elevator Car: The physical cabin that moves between floors.
• Elevator Controller: The “brain” that decides where the car should go next.
• Request Queues: Store pending floor requests (internal and external).
• Dispatcher (for multiple elevators): Assigns requests to the best elevator.
• Sensors: Track the car’s position, door status, and movement direction.
• User Interface: Floor buttons, display panels, and emergency controls.

Flow of a Request

1. A user presses a button on a floor (external request).
2. The request is sent to the dispatcher, which assigns it to an elevator.
3. The assigned elevator’s controller adds it to its internal queue.
4. The elevator moves, stops at the requested floor, and opens doors.
5. Passengers enter, press destination floors (internal requests).
6. The controller processes the new requests and continues.

Centralized vs Decentralized Control

• Centralized Control: A single dispatcher assigns all requests to elevators.
  • Advantage: Global optimization of traffic.
  • Disadvantage: Single point of failure.
• Decentralized Control: Each elevator manages its own requests with some coordination.
  • Advantage: More resilient and fault-tolerant.
  • Disadvantage: Harder to optimize globally.

Interview Tip

When asked to design an elevator system, describe both centralized and decentralized approaches, then explain which one you’d pick and why. For example:

• Centralized for skyscrapers with many elevators.
• Decentralized for smaller buildings with 2–3 elevators.

Data Model and Key Entities

When you design an elevator system, your data model defines how the system understands its components and interactions. A clean model helps you reason about behaviors, transitions, and scheduling.

Core Entities

• Elevator
  • Attributes: id, currentFloor, direction (UP, DOWN, IDLE), status (ACTIVE, MAINTENANCE).
  • Methods: moveUp(), moveDown(), openDoor(), closeDoor().
• Floor
  • Attributes: floorNumber, upButton, downButton.
  • Represents where requests originate.
• Request
  • Attributes: type (INTERNAL/EXTERNAL), sourceFloor, destinationFloor, timestamp.
  • Internal = passenger inside cabin; External = waiting user.
• Controller
  • Central logic that manages request queues, assigns elevators, and monitors states.
• Door
  • Attributes: status (OPEN, CLOSED, OPENING, CLOSING).
  • Safety logic ensures doors don’t close when blocked.

Example Class Diagram (Simplified)

+—————–+

| Elevator |

|—————–|

| id |

| currentFloor |

| direction |

| status |

+—————–+

| moveUp() |

| moveDown() |

| openDoor() |

| closeDoor() |

+—————–+

+—————–+

| Request |

|—————–|

| type |

| sourceFloor |

| destinationFloor|

| timestamp |

+—————–+

In interviews, modeling entities in a way that mirrors real-world objects shows that you know how to design an elevator system that is grounded and intuitive.

Handling User Requests

An elevator system revolves around requests. Users press buttons, and the system must capture, process, and fulfill them efficiently.

Two Types of Requests

• External Requests (Floor Calls):
  • Origin: hallway panels on each floor.
  • Example: pressing “Up” on the 5th floor.
  • Must be routed to an appropriate elevator.
• Internal Requests (Cabin Selections):
  • Origin: buttons inside the elevator cabin.
  • Example: choosing floor 10 after entering.
  • These are bound to the specific elevator already chosen by the dispatcher.

Request Flow

1. User presses a button → generates a request object.
2. Request is added to a queue (global for external, local for internal).
3. Controller (or dispatcher) assigns request to an elevator.
4. Assigned elevator adds it to its pending stops list.
5. Elevator moves to fulfill requests in sequence.

Key Considerations

• Concurrency: Multiple users may press buttons at once.
• Prioritization: Should an elevator stop for new requests mid-route?
• Fairness vs Efficiency: Minimize overall wait vs serving in strict order.
• Request Merging: If two people request the same floor, only one stop is needed.

Explaining this flow clearly will demonstrate that you understand the real-time and concurrent nature of the problem when you design an elevator system.

Scheduling Algorithms for Elevators

The heart of efficiency in elevator systems is the scheduling algorithm. When multiple requests are pending, the system must decide which elevator goes where and in what order.

Single Elevator Scheduling

• First Come First Serve (FCFS):
  • Simplest model. Serve requests in the order received.
  • Drawback: long wait times if requests are far apart.
• SCAN / LOOK Algorithms (like disk scheduling):
  • Elevator moves in one direction, serving all requests along the way.
  • Once it reaches the end, it reverses direction.
  • Example: If moving up, it stops at all requested upper floors before reversing.
  • Advantage: reduces travel time for clustered requests.

Multi-Elevator Scheduling

• Nearest Car Algorithm: Assigns the closest available elevator to the request.
• Load Balancing: Distributes requests evenly across elevators.
• Zoning: Divide building floors into zones, each handled by specific elevators.
• Dynamic Reassignment: Reassigns requests if a more optimal elevator becomes available.

Trade-Offs

• Fairness vs Efficiency: One elevator may serve many requests, while others stay idle.
• Idle Handling: Should idle elevators return to the lobby or spread across the building?
• Peak Load Strategy: Morning rush (everyone goes up) vs evening rush (everyone goes down).

In interviews, mentioning multiple algorithms and their trade-offs shows depth. If asked to design an elevator system, don’t just name one—explain why you’d choose it based on building size, floor count, and usage patterns.

State Management and Control Logic

When you design an elevator system, one of the most important aspects is defining the possible states of the elevator and how it transitions between them. Clear state management ensures predictable, safe, and efficient behavior.

Elevator States

• Idle: Elevator is not moving and is waiting for requests.
• Moving Up: Elevator is traveling upward to serve requests.
• Moving Down: Elevator is traveling downward.
• Loading/Unloading: Doors are open while passengers enter or exit.
• Out of Service: Elevator is unavailable due to maintenance or failure.

Door States

• Open / Opening
• Closed / Closing
• Obstructed (detected by sensors if something blocks the door).

State Transitions

• From Idle → Moving Up/Down when a request is received.
• From Moving → Loading/Unloading when the elevator reaches a stop.
• From Loading/Unloading → Idle if no more requests remain.
• From Any State → Out of Service in case of failure or manual override.

Control Logic

The controller enforces state transitions based on:

• Request queues (pending stops).
• Safety checks (doors closed before moving).
• Priority handling (emergency stop overrides regular requests).

Explaining states and transitions demonstrates to interviewers that you can design an elevator system that goes beyond the happy path and handles realistic scenarios.

Concurrency and Synchronization

Elevators deal with multiple users pressing buttons at the same time. Without proper concurrency control, you risk race conditions, duplicated requests, or inconsistent system behavior.

Concurrency Challenges

• Multiple floor requests arriving simultaneously.
• Two users inside different elevators requesting the same floor.
• Synchronization of shared resources like global request queues or dispatcher assignments.

Techniques for Synchronization

• Locks and Semaphores: Ensure only one thread modifies shared data (e.g., request queue) at a time.
• Concurrent Data Structures: Use thread-safe queues or maps for requests.
• Message Queues: Instead of direct shared memory, pass requests as events via a broker.
• Optimistic Concurrency: Allow parallel actions but validate before committing (used for reservations).

Example Scenario

• User A presses “Up” on floor 5 while User B presses “Down” on floor 7.
• Dispatcher evaluates both requests simultaneously.
• Synchronization ensures only one elevator is assigned to each request — no duplicate assignments.

Interviewers often push on concurrency. If you highlight how you’d prevent race conditions when you design an elevator system, you’ll stand out.

Fault Tolerance and Safety Mechanisms

Elevators are mission-critical systems; a small failure can endanger lives. That’s why fault tolerance and safety must be central to the design of an elevator system.

Fault Tolerance Principles

• Redundancy: Backup controllers and power supplies in case one fails.
• Failover Logic: If one elevator goes offline, other elevators absorb pending requests.
• Graceful Degradation: If real-time tracking fails, elevator still operates with local logic.

Safety Mechanisms

• Door Sensors: Prevent closing if an object or person blocks the doorway.
• Emergency Stop Button: Allows passengers to halt the elevator immediately.
• Overload Detection: Prevents movement if weight exceeds safe capacity.
• Fire and Earthquake Modes: Elevators bypass normal requests and move to a safe floor.

Error Handling

• Retry Logic: If a request assignment fails, it should be retried or reassigned.
• Logging and Alerts: Failures trigger alerts to maintenance teams.
• Simulation Testing: Systems must be tested under simulated failure conditions (power outage, network disruption).

Emphasizing safety proves you understand that to design an elevator system, you must balance performance with user trust and protection.

Scalability Considerations in Large Buildings

When you design an elevator system, scalability is critical. A two-story office building has very different needs than a 100-floor skyscraper. As buildings grow taller and traffic patterns change, your system must scale to maintain efficiency.

Scaling Challenges

• Request Volume: Dozens of requests per second during peak times.
• Wait Times: More floors mean longer travel distances, increasing delays.
• Multiple Elevator Banks: Tall buildings often have separate zones, each with dedicated elevators.
• Peak Traffic: Rush hours (morning/evening) create demand spikes that must be absorbed gracefully.

Techniques for Scaling

• Zoning: Divide floors into zones (e.g., 1–20, 21–40) and assign specific elevators to each. This reduces congestion.
• Express/Local Elevators: Some elevators skip intermediate floors and serve only designated “express” floors, improving throughput.
• Shuttle Systems: For very tall skyscrapers, shuttles move passengers to mid-level transfer lobbies where they switch to other elevators.
• Dynamic Assignment: Intelligent controllers reassign elevators based on live demand patterns.

Example

During morning rush hour, most requests are from the lobby upward. A scalable system might:

• Dedicate several elevators to exclusively handle lobby-to-upper-floor trips.
• Keep one elevator for reverse traffic (early departures).
• Balance load by predicting traffic patterns in advance.

In interviews, mentioning scalability shows that you’re thinking not only of functionality but also of performance under heavy load when you design an elevator system.

Monitoring, Metrics, and Performance Optimization

An elevator system must not only work. It must be continuously monitored and optimized. Without feedback loops, inefficiencies accumulate unnoticed. When you design an elevator system, observability helps operators ensure safety, efficiency, and user satisfaction.

Key Metrics to Track

• Average Wait Time: Time between button press and elevator arrival.
• Average Travel Time: Time between entering the elevator and reaching destination.
• Utilization: Percentage of time each elevator is active versus idle.
• Error Rates: Frequency of failed requests or missed stops.
• Load Metrics: Passenger counts per trip to track overloading risks.

Monitoring Tools

• Dashboards: Display real-time elevator states (current floor, direction, load).
• Alerts: Trigger notifications if average wait times exceed thresholds.
• Predictive Maintenance: Track motor usage, door cycles, and cable wear to schedule repairs before failures occur.

Optimization Strategies

• Use collected data to refine scheduling algorithms.
• Adjust zoning or dispatching during different times of day.
• Balance load across elevators to prevent overuse of certain shafts.

By showing how to measure and optimize, you prove you can design an elevator system that doesn’t stop at deployment—it includes long-term improvement.

Real-World Constraints and Trade-Offs

Theory is neat, but real-world systems always involve trade-offs. A perfect elevator design on paper may fail when cost, safety, and physical constraints are introduced. When you design an elevator system, acknowledging these trade-offs demonstrates practical thinking.

Common Trade-Offs

• Performance vs Cost: Faster elevators with advanced scheduling are expensive. Budget constraints often limit design choices.
• Space vs Capacity: Larger elevators hold more passengers but reduce rentable building space.
• Fairness vs Efficiency: Serving requests strictly in order may be fair, but optimizing for overall efficiency might delay some users.
• Energy vs Speed: Constantly running elevators fast consumes more energy. Energy-efficient designs may slightly increase wait times.

Real-World Constraints

• Accessibility: Elevators must accommodate wheelchairs and provide accessible controls.
• Safety Regulations: Compliance with building codes, fire evacuation procedures, and fail-safe standards is mandatory.
• Power Consumption: Elevators are one of the largest consumers of electricity in a building.
• User Behavior: Passengers may overload, hold doors open, or repeatedly press buttons — your system must handle these gracefully.

Showing awareness of constraints and trade-offs in a System Design interview highlights maturity. It proves you’re not just designing for a whiteboard, but also for real-world deployment.

Interview Preparation and Common Mistakes

If you’re asked to design an elevator system in an interview, it’s not about elevators alone—it’s about your ability to structure, prioritize, and communicate.

How to Approach the Question

1. Start with requirements.
   • Clarify: “How many floors? How many elevators? Are we optimizing for wait time or throughput?”
   • This shows you think before jumping into solutions.
2. Outline high-level architecture.
   • Identify core entities: Elevator, Controller, Request.
   • Sketch how requests move from user → controller → elevator.
3. Drill down into key components.
   • Scheduling logic: FCFS vs SCAN vs zoning.
   • State transitions: Idle → Moving → Loading.
   • Safety mechanisms: door sensors, emergency stop.
4. Discuss advanced aspects.
   • Concurrency handling (multiple requests at once).
   • Scalability (how to support 100+ floors).
   • Fault tolerance (backup systems and failover).
5. Wrap with trade-offs.
   • Mention cost, energy efficiency, and fairness vs performance.

Common Mistakes to Avoid

• Jumping straight into code or classes.
  Interviewers want structured thinking, not just implementation details.
• Ignoring scheduling.
  The heart of the problem is efficient request handling. If you skip it, your design feels incomplete.
• Forgetting safety.
  Doors, emergency stops, and overload detection aren’t optional.
• Not considering scalability.
  A system that works for 5 floors may collapse for 100 floors. Always address scaling.
• One-size-fits-all answers.
  Saying “I’ll just use FCFS” without reasoning shows shallow thinking. Always explain why your chosen approach fits the context.

The best candidates treat “design an elevator system” like any other System Design problem: clarify → structure → deep dive → trade-offs → wrap up.

Bringing It All Together

Designing an elevator system may seem simple at first glance, but when you break it down, it covers nearly every System Design principle:

• Requirements first: Understand what users need and how the system will be judged.
• Architecture clarity: Map out controllers, elevators, requests, and scheduling.
• Core logic: Handle requests efficiently and safely through smart scheduling algorithms.
• Scalability: Support small offices and massive skyscrapers with zoning and load balancing.
• Safety and reliability: Build trust with sensors, failover systems, and emergency handling.
• Real-world trade-offs: Balance performance, cost, energy, and fairness.

In interviews, when you’re asked to design an elevator system, your goal isn’t to produce the “perfect” solution. Instead, it’s to show that you can reason clearly, explain trade-offs, and adapt your design to context.

If you’d like to sharpen these skills, Grokking the System Design Interview is a fantastic resource. It provides structured approaches, real-world examples, and practice problems that will make tackling design challenges, like elevators, far more manageable.