Design a Simple Elevator System - Multiple Lifts

Design a multi-elevator coordination system with efficient request distribution.

What is the Elevator System - Multiple Lifts Problem?

Design a simple elevator system that manages 2-4 elevators in a building. The system should efficiently distribute requests across elevators, balance load to minimize wait times, optimize elevator direction based on requests, and handle concurrent requests from different floors.

In this problem, you’ll design a system that coordinates multiple elevators, assigns requests intelligently, and ensures efficient operation through state management and load balancing.

Problem Overview

Design an elevator system that coordinates multiple elevators (2-4) to serve building floors efficiently, with intelligent request assignment and direction optimization.

Core Requirements

Functional Requirements:

Multiple Elevator Cars: Manage 2-4 elevators in a building, each capable of accessing all floors.
Request Distribution: Efficiently distribute requests across elevators to minimize wait times.
Load Balancing: Balance load across elevators to prevent overloading any single elevator.
Direction Optimization: Optimize elevator direction (up/down) based on pending requests and current position.
Concurrent Requests: Handle multiple simultaneous requests from different floors without conflicts.
Idle State Management: When multiple elevators are idle, assign new requests to the closest idle elevator.
Request Types: Handle both external requests (from floor buttons) and internal requests (from inside elevator).
State Management: Track elevator states (idle, moving up, moving down, doors open) and handle transitions.
Display Updates: Notify displays and floor indicators when elevator states change.

Non-Functional Requirements:

Modular Design: Each class should have well-defined roles following the Single Responsibility Principle.
Extensibility: Easy to add new request assignment strategies or elevator features without refactoring.
Thread Safety: Request handling and elevator state updates must be thread-safe for concurrent requests.
Simple Coordination: Basic coordination without complex algorithms (unlike advanced SCAN/FCFS strategies).
Testability: Core elevator logic should be easy to test, understand, and maintain.

What’s Expected?

1. System Architecture

The system coordinates between users, the elevator system controller, multiple elevators, and display components.

2. Key Classes to Design

classDiagram
    class ElevatorSystem {
        -List~Elevator~ elevators
        -RequestAssignmentStrategy strategy
        +requestElevator(int, Direction) void
        +selectFloor(int, int) void
    }
    
    class Elevator {
        -int currentFloor
        -Direction direction
        -ElevatorState state
        -Queue~Request~ requestQueue
        +addRequest(Request) void
        +move() void
    }
    
    class RequestAssignmentStrategy {
        <<interface>>
        +selectElevator(List, Request) Elevator
    }
    
    class ElevatorState {
        <<interface>>
        +handleRequest(Elevator, Request) void
        +move(Elevator) void
    }

    ElevatorSystem --> Elevator
    ElevatorSystem --> RequestAssignmentStrategy
    Elevator --> ElevatorState
    ElevatorState <|.. IdleState
    ElevatorState <|.. MovingState
    RequestAssignmentStrategy <|.. ClosestIdleStrategy

System Flow

Request Assignment Flow

Key Design Challenges

1. Request Assignment Strategy

The system needs to choose which elevator should handle a request, considering factors like proximity, direction, and load.

Solution: Use the Strategy Pattern. Define a RequestAssignmentStrategy interface with implementations like ClosestIdleStrategy (prefer closest idle elevator, then closest moving elevator going in same direction). This makes the assignment algorithm swappable without modifying the elevator system.

2. Elevator State Management

Elevator behavior changes based on state (idle, moving up, moving down, doors open), and state transitions must be handled correctly.

Solution: Use the State Pattern. Define ElevatorState interface with implementations (IdleState, MovingState, DoorsOpenState). Each state encapsulates behavior for handling requests and movement, eliminating complex if-else chains.

3. Load Balancing

Requests should be distributed across elevators to prevent overloading any single elevator.

Solution: Implement load balancing through the request assignment strategy. Track pending requests per elevator and prefer elevators with fewer requests. Combine with closest-idle logic to balance proximity and load.

4. Concurrent Request Handling

Multiple users can request elevators simultaneously from different floors, requiring thread-safe operations.

Solution: Implement thread-safe operations using synchronized methods, thread-safe collections (ConcurrentHashMap, thread-safe queues), and fine-grained locking. Ensure request queue operations and state updates are atomic.

What You’ll Learn

By solving this problem, you’ll master:

✅ State Management - Controlling complex object lifecycles with the State Pattern.
✅ Strategy Pattern - Swappable algorithms for request assignment.
✅ Load Balancing - Distributing work across multiple resources.
✅ Observer Pattern - Decoupled notifications to multiple displays.
✅ Concurrency - Thread-safe operations for concurrent requests.

View Complete Solution & Practice

Ready to see the full implementation? Open the interactive playground to access:

🎯 Step-by-step guidance through the 8-step LLD approach
📊 Interactive UML builder to visualize your design
💻 Complete Code Solutions in Python, Java, C++, TypeScript, JavaScript, C#
🤖 AI-powered review of your design and code

🚀 View Solution in Playground

After mastering Elevator System - Multiple Lifts, try these similar problems:

Elevator System - Single Lift - Single elevator with request queue management.
Elevator System - Request Feasibility - Advanced feasibility checking.
Task Scheduler - Resource scheduling and coordination.