Getting Ready: Elevator System

Every modern building with more than a few stories relies on an elevator system. Companies like Otis, ThyssenKrupp, Schindler, and KONE have spent over a century perfecting elevator scheduling — and the core challenge remains a fascinating computer science problem: how do you move N cars across M floors to serve requests with minimal wait time and minimal travel distance?

This problem is a favorite in LLD interviews at companies like Amazon, Google, Microsoft, and Uber because it tests multiple design skills at once. You need to model stateful objects (an elevator has direction, current floor, and a request queue), apply the Strategy Pattern for swappable scheduling algorithms, use the State Pattern for direction management, and coordinate multiple elevators with an intelligent dispatcher. It's one of the first problems where you encounter a real algorithm choice — FCFS, SCAN, and LOOK each produce different performance characteristics, and an interviewer will expect you to explain the trade-offs.

Unlike simpler problems like a Parking Lot or Vending Machine, the Elevator System introduces continuous motion: the elevator doesn't just transition between discrete states — it moves through floors over time, serving requests along the way. This creates unique challenges around request ordering, direction optimization, and starvation prevention that don't exist in static-state problems.

In this design problem, you will:

• Model an elevator's state machine — Idle, Moving Up, Moving Down, and Door Open states with clear transitions
• Apply the Strategy Pattern to make scheduling algorithms (FCFS, SCAN, LOOK) interchangeable at runtime
• Apply the State Pattern to manage elevator direction and behavior changes
• Apply the Observer Pattern to update floor displays and arrival notifications
• Design a multi-elevator dispatcher that assigns incoming requests to the optimal car
• Implement three scheduling algorithms — understand why SCAN outperforms FCFS and how LOOK improves on SCAN
• Create UML diagrams — Use Case, State Machine, and Class diagrams that drive the implementation
• Write complete, runnable code in Python and Java matching the class diagram exactly

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition and Association (Fundamentals S4). The ElevatorSystem composes Elevators; Elevators associate with Requests.
• State Pattern — how objects change behavior based on internal state (Fundamentals S12). Each elevator direction is a state with distinct behavior.
• Strategy Pattern — swapping algorithms at runtime via a common interface (Fundamentals S12). Scheduling algorithms are interchangeable strategies.
• Observer Pattern — notifying dependent objects of state changes (Fundamentals S12). Floor displays observe elevator position.
• UML Class & State Machine Diagrams — reading and interpreting them (Fundamentals S5). We'll build both diagram types for this problem.
• Enums — modeling fixed sets of values like Direction, DoorStatus, and ElevatorState (Fundamentals S3).

If you've completed the Easy problems (DP1–DP7), you've already applied most of these concepts individually. The Elevator System is your first Medium problem — it combines multiple patterns in a single design and introduces algorithm-level decision-making.

We will design: The core domain logic for an elevator control system — elevator cars with state management, a request dispatcher, scheduling algorithms (FCFS, SCAN, LOOK), floor request buttons, and display panels. The focus is on object modeling and algorithmic decision-making.

We will NOT design: Physical motor control, distributed systems across multiple buildings, database schemas, REST APIs, weight sensors, emergency braking hardware, or UI/frontend. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

Key simplifications:

• We assume floors are numbered 1 to N (no basement floors, though extending the design is trivial)
• Travel time between floors is uniform (1 unit per floor)
• Door open/close time is constant
• We don't model passenger capacity or weight limits (though we'll discuss this as an extension)

Before we design anything, let's understand how real commercial elevator systems operate — this domain knowledge directly informs our class design.

Two types of requests:

• Hall calls (external): A person on floor 5 presses the UP button. They don't specify a destination yet — they just want an elevator going up. The system must decide WHICH elevator to send.
• Cabin calls (internal): Once inside, the passenger presses floor 12. This request is specific to the elevator they're in.

The fundamental scheduling challenge:
Imagine a 20-floor building with 4 elevators. Elevator A is on floor 3 going up, Elevator B is on floor 15 going down, Elevator C is idle on floor 8, and Elevator D is on floor 10 going up. A hall call comes from floor 7 requesting UP. Which elevator should respond?

• Elevator C is closest (2 floors away) but idle — it needs to start moving.
• Elevator D is going up and will pass floor 7 — it can pick up the passenger "on the way" with zero detour.
• Elevator A is going up from floor 3 — it could serve floor 7 but is further away.
• Elevator B is going DOWN past floor 7 — assigning it would mean it has to reverse direction, wasting time.

This is the elevator dispatch problem — and the algorithm choice (FCFS, SCAN, LOOK) determines how efficiently requests are served. We'll implement all three and compare them in the Scheduling Algorithms tutorial.