Design an Elevator System

Multi-car, multi-floor scheduling with state-driven door logic.

Advanced18 min read

Read these first

Design a Parking Lot System

Why this matters

Multiple elevators serve multiple floors in one building
Scope — what "State machine" covers inside Elevator System and what it does not
Scope — what "Scheduling" covers inside Elevator System and what it does not
Scope — what "Concurrency" covers inside Elevator System and what it does not
Machine problems test State, Strategy, and facade coordination.

Idle

Moving

DoorOpen

Idle

State pattern keeps door logic separate from movement logic.

CampusOS context

CampusOS is the fictional smart-campus platform used across this track. Treat this module as a real product slice:

Context

Belongs to CampusOS — same naming and design vocabulary as parking, library, and booking modules
Scope is one JVM — persistence is in-memory or behind a repository interface
Goal is a class diagram + core Java that an interviewer can follow in 35–45 minutes
Extension paragraph at the end links to System Design when scale exceeds one process

Requirements snapshot

Functional requirements

Multiple elevators serve multiple floors in one building
Passengers request up/down on a floor or select destination inside the car
Elevator moves floor-by-floor; doors open on arrival, close before moving
Scheduler picks which car serves a request (nearest, SCAN, or simple FIFO)
Display panel shows current floor and direction per car
Emergency stop halts movement and opens doors safely

Non-functional requirements

Thread-safe scheduler if multiple requests arrive concurrently
Deterministic state transitions per elevator car
Scheduling algorithm pluggable (Strategy pattern)
In-process simulation; no real hardware drivers required

Overview

This CampusOS module designs Elevator System as a production-ready in-process service. Read requirements point-by-point before drawing classes.

Requirements

Points to cover

Multiple elevators serve multiple floors in one building
Passengers request up/down on a floor or select destination inside the car
Elevator moves floor-by-floor; doors open on arrival, close before moving
Scheduler picks which car serves a request (nearest, SCAN, or simple FIFO)
Display panel shows current floor and direction per car
Emergency stop halts movement and opens doors safely

State machine

Points to cover

Scope — what "State machine" covers inside Elevator System and what it does not
Classes — name 2–4 classes/interfaces responsible for this slice
Flow — step-by-step: trigger → validation → state change → side effect
Edge cases — invalid input, concurrent access, empty state, timeout
Pattern — Strategy, State, Observer, or Facade if it fits naturally
Test hook — one scenario an interviewer will ask you to walk through

Scheduling

Points to cover

Scope — what "Scheduling" covers inside Elevator System and what it does not
Classes — name 2–4 classes/interfaces responsible for this slice
Flow — step-by-step: trigger → validation → state change → side effect
Edge cases — invalid input, concurrent access, empty state, timeout
Pattern — Strategy, State, Observer, or Facade if it fits naturally
Test hook — one scenario an interviewer will ask you to walk through

Concurrency

Points to cover

Scope — what "Concurrency" covers inside Elevator System and what it does not
Classes — name 2–4 classes/interfaces responsible for this slice
Flow — step-by-step: trigger → validation → state change → side effect
Edge cases — invalid input, concurrent access, empty state, timeout
Pattern — Strategy, State, Observer, or Facade if it fits naturally
Test hook — one scenario an interviewer will ask you to walk through

Java

// CampusOS — ElevatorSystem facade (keep thin)
public final class ElevatorSystemService {
    private final ElevatorSystemRepository repository;

    public ElevatorSystemService(ElevatorSystemRepository repository) {
        this.repository = repository;
    }

    /** Orchestrate: validate → domain rules → persist → return result */
    public Result handle(Request request) {
        request.validate();
        var domain = DomainModel.from(request);
        domain.applyRules();
        return repository.save(domain);
    }
}

Quick recall

Everything you need if you only revisit this box.

Requirements — review this slice before mock interviews.
State machine — review this slice before mock interviews.
Scheduling — review this slice before mock interviews.
Concurrency — review this slice before mock interviews.

CampusOS extension

When this outgrows one JVM

Shard inventory or state by campus ID or geographic region
Push notifications, payments, and search to dedicated services (System Design track)
Use message queues for async side effects (email, analytics)
The class diagram you drew here becomes one box on the HLD architecture diagram

Test yourself

Answer these before moving on — recall is what makes it stick.