An elevator system appears simple on the surface: press a button, go to a floor. But beneath that simplicity lies a rich design problem involving state machines, scheduling algorithms, and real-time coordination. The reason elevator systems appear in OOD interviews is that they force you to think about concurrency, fairness, and optimization simultaneously. Every design decision affects how long people wait, how efficiently the system uses energy, and how gracefully it handles edge cases.

Before writing any code, you need to understand what the system must do and who interacts with it.

Actors and Interactions

Two types of users interact with the system:

Passengers on a floor press a hall button (up or down) to request an elevator. They do not choose which elevator comes: the system decides. They only express intent: "I want to go up" or "I want to go down."

Passengers inside an elevator press a cabin button to select their destination floor. This request is specific to the elevator they are in: it cannot be rerouted to another elevator.

The system itself has a third role: the dispatcher, which decides which elevator handles each hall request. This is where the interesting design decisions happen.

Functional Requirements

• Support N elevators in a building with M floors
• Handle hall requests (floor + direction) from passengers waiting on a floor
• Handle cabin requests (destination floor) from passengers inside an elevator
• Move elevators floor by floor, opening doors when they arrive at a requested floor
• Dispatch hall requests to the most suitable elevator

Non-Functional Requirements

• Fairness: no passenger should wait indefinitely while others are served repeatedly
• Efficiency: minimize total travel distance and average wait time
• Responsiveness: the system should acknowledge requests immediately even if service takes time

Core Entities Preview

From the requirements, you can identify the key objects:

• Elevator: has a current floor, direction, state, and a queue of requests
• Request: represents either a hall request (floor + direction) or a cabin request (destination floor)
• ElevatorSystem: manages all elevators and dispatches hall requests
• Button: hall buttons on each floor and cabin buttons inside each elevator
• Door: opens and closes with safety checks
• Display: shows current floor and direction on each floor and inside each cabin

The next sections will model these entities, implement scheduling algorithms, and handle the coordination and edge cases that make this problem challenging.