Elevator System Design - Complete Low-Level Design Guide

Design a scalable Elevator Control System using Java and Spring Boot. Learn requirement analysis, UML class diagrams, elevator scheduling algorithms, concurrency, SOLID principles, design patterns, state machines, and enterprise architecture.

Introduction

The Elevator System is one of the most common Low-Level Design (LLD) interview questions because it demonstrates a developer's ability to model real-world systems involving scheduling, state management, concurrency, and object-oriented design.

Large office buildings, shopping malls, hospitals, airports, and residential apartments rely on intelligent elevator systems to efficiently transport thousands of people every day.

A poorly designed elevator system results in:

Long waiting times
Unnecessary movement
Increased energy consumption
Passenger dissatisfaction

In this guide, we'll design a production-ready Elevator Control System using Java and Spring Boot while applying SOLID principles, design patterns, and enterprise architecture.

Problem Statement

Design an Elevator System that supports:

Multiple Elevators
Multiple Floors
Internal Requests
External Requests
Elevator Scheduling
Door Control
Emergency Mode
Maintenance Mode
Floor Display
Capacity Limits

Functional Requirements

The system should support:

Call Elevator
Select Destination Floor
Move Up
Move Down
Open Door
Close Door
Emergency Stop
Maintenance Mode
Floor Display
Elevator Status
Request Queue
Alarm System

Non-Functional Requirements

The system should be:

Highly Available
Thread Safe
Fault Tolerant
Extensible
Maintainable
Scalable
Low Latency

Actors

Actors include:

Passenger
Elevator
Elevator Controller
Building Management System
Maintenance Engineer

High-Level Architecture

flowchart TD
    PASS["Passenger Request"]

    CONTROLLER["Elevator Control System"]

    SCHED["Dispatch Scheduler"]

    ELEVATORS["Elevator Fleet"]

    E1["Elevator A"]
    E2["Elevator B"]
    E3["Elevator C"]

    SENSORS["Floor Sensors"]
    DOOR["Door Control System"]

    PASS --> CONTROLLER --> SCHED --> ELEVATORS

    ELEVATORS --> E1
    ELEVATORS --> E2
    ELEVATORS --> E3

    E1 --> SENSORS
    E2 --> SENSORS
    E3 --> SENSORS

    E1 --> DOOR
    E2 --> DOOR
    E3 --> DOOR

Core Components

The system consists of:

Elevator Controller
Elevator
Floor
Elevator Car
Door
Request
Scheduler
Display Panel
Motor
Sensor

Domain Model

classDiagram

class ElevatorController

class Elevator

class Request

class Floor

class Door

class Motor

class Display

ElevatorController --> Elevator

Elevator --> Door

Elevator --> Motor

Elevator --> Display

Elevator --> Request

Request --> Floor

Entity Responsibilities

Elevator Controller

Responsible for:

Managing all elevators
Assigning requests
Scheduling movement

Elevator

Stores:

Elevator ID
Current Floor
Direction
Status
Capacity
Pending Requests

Floor

Stores:

Floor Number
Up Button
Down Button

Door

Responsible for:

Open
Close
Lock

Motor

Responsible for:

Moving Up
Moving Down
Stop

Request

Stores:

Source Floor
Destination Floor
Direction

Elevator States


Idle

Moving Up

Moving Down

Door Open

Door Closed

Maintenance

Emergency

Passenger Workflow

sequenceDiagram

participant Passenger

participant Controller

participant Elevator

Passenger->>Controller: Press Up Button

Controller->>Elevator: Assign Request

Elevator-->>Passenger: Arrives

Passenger->>Elevator: Select Floor

Elevator-->>Passenger: Reach Destination

External Request

Passenger requests an elevator.

flowchart LR
    REQUEST["Floor Button Press"]

    CONTROLLER["Elevator Control System"]

    SCHEDULER["Dispatch Scheduler"]

    ELEVATOR["Optimal Elevator Selection"]

    REQUEST --> CONTROLLER --> SCHEDULER --> ELEVATOR

Internal Request

Inside elevator:


Floor Selected

↓

Queue Request

↓

Move Elevator

Elevator Lifecycle

flowchart LR
    IDLE["Idle State"]

    REQUEST["Request Received"]

    MOVING["Moving to Floor"]

    OPEN["Door Open"]

    CLOSE["Door Close"]

    IDLE --> REQUEST --> MOVING --> OPEN --> CLOSE --> IDLE

Request Queue

Each elevator maintains two queues:

Up Requests
Down Requests

This minimizes unnecessary movement.

Scheduling Algorithms

Common algorithms:

First Come First Serve (FCFS)
Nearest Elevator
LOOK Algorithm
SCAN Algorithm
Elevator Algorithm
Dynamic Priority Scheduling

Nearest Elevator Strategy

flowchart LR
    REQUEST["Floor Request"]

    CONTROLLER["Elevator Controller"]

    DISPATCH["Dispatch Engine"]

    ASSIGN["Elevator Assignment System"]

    REQUEST --> CONTROLLER --> DISPATCH --> ASSIGN

The closest idle elevator is selected.

SCAN (Elevator Algorithm)

The elevator continues moving in one direction until all requests are served.

Example:


Floor 1

↓

3

↓

5

↓

8

↓

10

Then it changes direction.

This minimizes travel time.

Capacity Handling

Each elevator has:


Maximum Weight

Maximum Passengers

If capacity is exceeded:

Reject new passengers
Display overload warning

Door Operations

flowchart LR
    ARRIVE["Elevator Arrives at Floor"]

    OPEN["Door Opens"]

    EXIT["Passengers Exit"]

    ENTER["Passengers Enter"]

    CLOSE["Door Closes"]

    ARRIVE --> OPEN --> EXIT --> ENTER --> CLOSE

Doors remain open for a configurable duration.

Emergency Mode

Emergency situations include:

Fire Alarm
Power Failure
Emergency Button

Behavior:

Stop elevator safely
Open doors if possible
Disable new requests

Maintenance Mode

Maintenance engineer can:

Disable elevator
Run diagnostics
Test movement
Return elevator to service

Design Patterns

Singleton

Elevator Controller

One controller manages all elevators.

Factory Pattern

Create different elevator types.

Examples:

Passenger Elevator
Freight Elevator
Service Elevator
Express Elevator

Strategy Pattern

Scheduling algorithms.

Examples:

FCFS
Nearest Elevator
LOOK
SCAN

State Pattern

Elevator State.


Idle

↓

Moving

↓

Door Open

↓

Door Closed

Observer Pattern

Display boards update automatically.

Subscribers:

Floor Display
Elevator Display
Monitoring Dashboard

SOLID Principles

SRP

Each class performs one responsibility.

OCP

New scheduling algorithms can be added without modifying controller logic.

LSP

Every elevator type behaves as an Elevator.

ISP

Separate interfaces:

Movement
Door
Display

DIP

Controller depends on scheduler interface.

Concurrency

Multiple passengers can request elevators simultaneously.

Challenges:

Duplicate assignment
Conflicting requests
Race conditions

Solutions:

Thread-safe queues
Locks
Atomic request assignment
Concurrent collections

Database Design


Elevator

Floor

Request

MaintenanceLog

EmergencyLog

Spring Boot Layers

flowchart LR

Controller

-->

Service

-->

Repository

-->

Database

REST APIs


POST /elevator/request

POST /elevator/internal

GET /elevators

GET /floors

POST /maintenance

POST /emergency

Enterprise Architecture

flowchart TD
    CLIENT["Mobile App"]

    GATEWAY["API Gateway"]

    CONTROLLER["Elevator Control System"]

    SCHEDULER["Dispatch Scheduler"]

    SERVICE["Elevator Service Layer"]

    DATABASE["PostgreSQL DB"]
    CACHE["Redis Cache"]
    STREAM["Kafka Event Stream"]
    OBS["Monitoring Dashboard"]

    CLIENT --> GATEWAY --> CONTROLLER --> SCHEDULER --> SERVICE

    SERVICE --> DATABASE
    SERVICE --> CACHE
    SERVICE --> STREAM
    SERVICE --> OBS

Redis stores active requests.

Kafka publishes events:

ElevatorAssigned
ElevatorArrived
DoorOpened
DoorClosed
EmergencyTriggered

Scaling Considerations

Large buildings may have:

Hundreds of Floors
Dozens of Elevators
Thousands of Daily Requests

Scaling techniques:

Distributed Scheduler
Redis
Kafka
Horizontal Scaling
Monitoring
Event Streaming

Future Enhancements

Possible features:

AI-based Scheduling
Destination Control System
Mobile App Calling
Voice Commands
Face Recognition
IoT Monitoring
Predictive Maintenance
Energy Optimization
VIP Priority Mode
Smart Traffic Prediction

Common Mistakes

❌ Using one queue for all requests.

❌ Ignoring direction.

❌ No overload handling.

❌ No emergency mode.

❌ Tight coupling between controller and scheduler.

❌ No concurrency handling.

Interview Questions

How would you assign the nearest elevator?
Explain the SCAN (Elevator) algorithm.
How would you prevent conflicting requests?
Which design patterns are useful?
How would you support express elevators?
How would you optimize waiting time?
How would you implement maintenance mode?
How would Redis improve the system?
How would you support multiple buildings?
How would you design an AI-based elevator scheduler?

Summary

The Elevator System is an excellent Low-Level Design problem because it combines scheduling algorithms, state management, concurrency, and object-oriented modeling.

A production-ready implementation should include:

Rich domain entities
Layered Spring Boot architecture
SOLID principles
Factory, Strategy, Singleton, State, and Observer patterns
Intelligent scheduling
Thread-safe request handling
REST APIs
Redis for active request queues
Kafka for event streaming
Monitoring and maintenance support

Mastering this design prepares you for advanced scheduling and resource allocation problems such as Cab Booking, Warehouse Robots, Hospital Bed Allocation, Airport Gate Management, and Distributed Task Scheduling, where optimization, concurrency, and state management are essential.