Design Elevator System (LLD)

1. Requirements

Functional
- Building has floors and one or more elevator cars; passengers request up/down from hall or choose destination inside cab.
- Dispatch assigns cars to pick up and drop off passengers according to a scheduling policy.
- Cars move floor-to-floor with doors that open when idle at a serviced stop.
- Support emergency stop and maintenance mode (optional in scope).
Non-Functional
- Dispatch decisions must be explainable and safe (no skipping mandatory stops incorrectly).
- Extensible scheduling (SCAN, LOOK, FCFS) without rewriting car physics.
- Reasonable worst-case response under concurrent hall calls.
Assumptions / Out of Scope
- Single controller process; no distributed consensus for one building.
- Weight sensor and fire-safety interlocks described as interfaces only.

2. Core Entities

Entity	Responsibility	Key Attributes
Building	Owns floors and elevator shafts	identifier, floors, cars
ElevatorCar	Vertical transport unit	identifier, currentFloor, direction, doorState, load
Floor	Vertical position index	index, hallButtons
DispatchController	Assigns cars to requests	policy, requestQueues
ElevatorRequest	Intent to travel	sourceFloor, destinationFloor, directionHint
SchedulingPolicy	Orders stops for a car	name, nextStop logic

3. Class Diagram

Loading diagram…

4. State / Sequence Diagram (where relevant)

Loading diagram…

5. Design Patterns Applied

Strategy — Swappable SchedulingPolicy (SCAN, LOOK). See Strategy pattern.
State — Door and motion states on ElevatorCar. See State pattern.
Observer — Floors emit hall-call events to controller. See Observer pattern.

6. Implementation

Go

package elevator

type Direction int

type ElevatorCar struct {
    Identifier   string
    CurrentFloor int
    Moving       Direction
    DoorOpen     bool
    InternalStops map[int]struct{}
}

type DispatchController struct {
    Cars   []*ElevatorCar
    Policy SchedulingPolicy
}

func (controller *DispatchController) SubmitHallCall(floor int, direction Direction) { /* ... */ }
func (controller *DispatchController) Tick() { /* advances simulation / scheduler */ }

JavaScript

class ElevatorCar {
  constructor({ identifier, startingFloor }) {
    this.identifier = identifier;
    this.currentFloor = startingFloor;
    this.direction = 'idle';
    this.doorOpen = false;
    this.internalStops = new Set();
  }
}

class DispatchController {
  constructor({ cars, schedulingPolicy }) {
    this.cars = cars;
    this.schedulingPolicy = schedulingPolicy;
  }
  submitHallCall({ floorIndex, direction }) { /* ... */ }
  tick() { /* ... */ }
}

7. Concurrency / Thread Safety

Collisions: Concurrent hall calls mutating one car's stop set; concurrent tick vs external submit.
Granularity: One mutex per car for stop sets and door state; controller serializes global dispatch step or uses channel per car in Go.
Go: sync.Mutex on each ElevatorCar; controller loop receives events on channel.
JavaScript: Single event loop; use explicit queue for simulation ticks if workers added later.

8. Extensibility & Followups

Destination dispatch: passengers enter target floor at lobby before boarding.
Energy optimization: idle parking floor policy as another SchedulingPolicy.
Multi-shaft: partition hall calls by zone then merge results.
Edge cases: overload, door obstruction retries, power loss mid-move.

On this page