Loading low-level design…

Design an Elevator System - Low-Level Design | OneNoughtOne

00:00:00

Design an Elevator System

Intermediate

Design an object-oriented elevator system that manages multiple elevators in a building with M floors. The system handles external requests (floor buttons) and internal requests (cabin buttons), dispatches the optimal elevator using a pluggable strategy, and moves elevators using a SCAN/LOOK scheduling algorithm.

The controller coordinates all elevators, each of which maintains its own stop list and direction state. The dispatch strategy (nearest-elevator, zone-based, etc.) can be swapped at runtime.

Core Use Cases

External request (floor button)

A person on a floor presses UP or DOWN to request an elevator

Internal request (cabin button)

A passenger inside the elevator presses a destination floor

Dispatch elevator

Controller selects the optimal elevator for each external request

Move and stop

Elevator moves floor by floor, opening doors at requested stops

Direction management

Elevator continues in one direction, serving all stops, before reversing (SCAN/LOOK)

Multiple elevators

System manages N elevators across M floors concurrently

Pluggable dispatch strategy

Swap between nearest-elevator, zone-based, or other scheduling algorithms

Constraints

An elevator can only move one floor per time step
Doors must close before the elevator moves
An elevator serves all stops in its current direction before reversing (LOOK algorithm)
Only one dispatch strategy is active at a time, but it can be swapped at runtime
Floor numbers are contiguous integers from minFloor to maxFloor

Assumptions

Elevator capacity is unlimited (weight limit is a follow-up)
Door open/close is instantaneous for simplicity
No priority requests (VIP / fire service — follow-up)
Single building, no inter-building transfers
Simulation advances in discrete time steps

In Scope

Elevator state machine (idle, moving up, moving down, doors open)
External and internal request handling
Dispatch strategy abstraction (nearest, zone-based)
SCAN/LOOK scheduling within each elevator
Multi-elevator coordination via controller

Out of Scope

Passenger capacity / weight limits
Physical acceleration, deceleration, and timing
Emergency stop / fire mode
Display panels and audio announcements
Energy consumption optimisation

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Loading LLD design...

00:00:00

Design an Elevator System

Intermediate

The controller coordinates all elevators, each of which maintains its own stop list and direction state. The dispatch strategy (nearest-elevator, zone-based, etc.) can be swapped at runtime.

Core Use Cases

External request (floor button)

A person on a floor presses UP or DOWN to request an elevator

Internal request (cabin button)

A passenger inside the elevator presses a destination floor

Dispatch elevator

Controller selects the optimal elevator for each external request

Move and stop

Elevator moves floor by floor, opening doors at requested stops

Direction management

Elevator continues in one direction, serving all stops, before reversing (SCAN/LOOK)

Multiple elevators

System manages N elevators across M floors concurrently

Pluggable dispatch strategy

Swap between nearest-elevator, zone-based, or other scheduling algorithms

Constraints

An elevator can only move one floor per time step
Doors must close before the elevator moves
An elevator serves all stops in its current direction before reversing (LOOK algorithm)
Only one dispatch strategy is active at a time, but it can be swapped at runtime
Floor numbers are contiguous integers from minFloor to maxFloor

Assumptions

Elevator capacity is unlimited (weight limit is a follow-up)
Door open/close is instantaneous for simplicity
No priority requests (VIP / fire service — follow-up)
Single building, no inter-building transfers
Simulation advances in discrete time steps

In Scope

Elevator state machine (idle, moving up, moving down, doors open)
External and internal request handling
Dispatch strategy abstraction (nearest, zone-based)
SCAN/LOOK scheduling within each elevator
Multi-elevator coordination via controller

Out of Scope

Passenger capacity / weight limits
Physical acceleration, deceleration, and timing
Emergency stop / fire mode
Display panels and audio announcements
Energy consumption optimisation

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Design an Elevator System

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design an Elevator System

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design an Elevator System

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you add passenger capacity / weight limits?

2How would you implement a VIP / express elevator that skips certain floors?

3How would you optimise for minimum total wait time across all passengers?

4How would you add a fire/emergency mode?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions

Design an Elevator System

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you add passenger capacity / weight limits?

2How would you implement a VIP / express elevator that skips certain floors?

3How would you optimise for minimum total wait time across all passengers?

4How would you add a fire/emergency mode?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions