Multiple elevator coordination in LLD - System Design Exercise

Design: Multiple Elevator Coordination System

Design focuses on the coordination logic and communication between elevators and control system. Hardware details of elevators and physical sensors are out of scope.

Functional Requirements

FR1: Support multiple elevators in a building with up to 20 floors

FR2: Handle elevator requests from any floor (up/down buttons) and inside elevators (floor selection)

FR3: Efficiently assign elevators to requests to minimize wait and travel time

FR4: Support concurrent requests and real-time updates of elevator positions and states

FR5: Provide status of each elevator (idle, moving up/down, door open/closed)

FR6: Handle edge cases like simultaneous requests, elevator overload, and emergency stop

Non-Functional Requirements

NFR1: System must respond to requests with p99 latency under 100ms

NFR2: Support up to 10 concurrent elevators and 100 concurrent requests

NFR3: High availability with 99.9% uptime

NFR4: Low memory footprint suitable for embedded elevator controllers

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Elevator controller module per elevator

Central coordination system or distributed coordination

Request queue or priority queue for pending calls

State management for elevator position, direction, and door status

Communication protocol between elevators and coordinator

Design Patterns

Observer pattern for state updates

Priority queue for request scheduling

Finite state machine for elevator states

Load balancing algorithms for request assignment

Event-driven architecture for real-time updates

Reference Architecture

          +-----------------------+
          |  Central Coordinator   |
          |  - Request Scheduler   |
          |  - Elevator State DB   |
          +-----------+-----------+
                      |
          +-----------+-----------+-----------+-----------+
          |           |           |           |           |
    +-----v-----+ +---v-----+ +---v-----+ +---v-----+ +---v-----+
    | Elevator 1| |Elevator2| |Elevator3| |Elevator4| |Elevator5|
    | Controller| |Controller| |Controller| |Controller| |Controller|
    +-----------+ +---------+ +---------+ +---------+ +---------+

Each Elevator Controller communicates with Central Coordinator to receive assignments and report status.

Components

Central Coordinator

In-memory scheduler service

Receives all elevator requests, maintains elevator states, assigns requests to elevators efficiently

Elevator Controller

Embedded controller software

Controls individual elevator movement, doors, and reports status to coordinator

Request Queue

Priority queue data structure

Stores pending floor requests prioritized by direction and proximity

State Database

In-memory key-value store

Stores real-time elevator positions, directions, and door states

Communication Protocol

Lightweight message passing (e.g., MQTT or custom TCP)

Enables real-time bidirectional communication between coordinator and elevators

Request Flow

1. User presses floor button inside elevator or call button on a floor

2. Elevator Controller sends request to Central Coordinator

3. Coordinator adds request to Request Queue

4. Scheduler evaluates all pending requests and elevator states

5. Coordinator assigns request to best elevator based on current position and direction

6. Assigned Elevator Controller receives request and updates its internal queue

7. Elevator moves to requested floor, opens doors, and updates status to Coordinator

8. Coordinator updates State Database and removes completed request

9. System repeats for new incoming requests

Database Schema

Entities: - Elevator: id (PK), current_floor, direction (up/down/idle), door_status (open/closed), load_status - Request: id (PK), floor_number, direction (up/down), status (pending/assigned/completed), assigned_elevator_id (FK) Relationships: - One Elevator can have many Requests assigned - Requests are linked to one Elevator when assigned - State Database holds current Elevator states and Request statuses

Scaling Discussion

Bottlenecks

Central Coordinator becomes a single point of failure and bottleneck with many elevators

Request Queue contention under high request volume

Communication delays between elevators and coordinator

Memory limits on embedded controllers for state tracking

Solutions

Implement distributed coordination with partitioned floors or elevator groups

Use concurrent priority queues with locking or lock-free data structures

Optimize communication with lightweight protocols and batch updates

Offload complex scheduling logic to cloud or edge servers, keep controllers simple

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 15 minutes designing components and data flow, 10 minutes discussing scaling and edge cases, 10 minutes summarizing and answering questions.

Clarify number of elevators and floors early

Explain trade-offs in scheduling algorithms (e.g., nearest elevator vs. load balancing)

Describe how state is tracked and updated in real-time

Discuss failure handling and emergency scenarios

Highlight scalability challenges and solutions