Codemia | Master System Design Interviews Through Active Practice

My Solution for Design an Elevator System with Score: 9/10

by nectar4678

Requirements

To design an effective elevator control system, it’s essential to first understand the variety of ways it will be used. This system is not just about moving elevators up and down; it must serve diverse use cases and user groups while ensuring optimal performance and safety.

In a building with multiple floors, there are typically two main user groups: residents or office workers who use elevators for regular transport, and building administrators who oversee operations and maintenance. Both groups have distinct requirements.

For users, the system should handle elevator requests efficiently, ensuring minimal wait times and prioritizing fairness, such as serving requests in the order they were made. Additionally, it should adapt to real-world scenarios like high traffic during peak hours and the occasional urgent request (e.g., a priority for fire evacuation). For administrators, the system must support operational modes like maintenance (taking elevators offline without disrupting others) and emergency (prioritizing safety).

An essential requirement is optimizing elevator movement to reduce unnecessary stops, improving energy efficiency while maintaining responsiveness. This calls for logic to determine when elevators should remain idle, cluster on specific floors, or handle specific zones during peak hours. Other operational features include handling invalid or redundant requests, ensuring safety compliance, and integrating alarms or override mechanisms for emergencies.

Define Core Objects

With the requirements established, the next step is to identify the fundamental components that will bring this elevator system to life. These objects represent the key players in the system and encapsulate the logic and data necessary to fulfill the requirements.

At its core, the elevator control system will include the following objects:

Elevator: This represents a single elevator unit. Each elevator has attributes like its current floor, direction (up, down, or idle), and status (active, maintenance, emergency). The Elevator object also includes the logic for moving between floors, responding to requests, and handling door operations.
Floor: Floors serve as points of interaction between users and elevators. A Floor object will maintain a list of requests (up or down) and provide interfaces for users to make these requests.
Request: A Request object encapsulates a user’s call for an elevator, storing details such as the origin floor, direction, and any priority flags (e.g., emergency calls).
ElevatorController: This is the brain of the system, coordinating multiple elevators and managing the distribution of requests. It must make optimization decisions, such as assigning the closest elevator to a request or determining movement patterns during peak hours.
UserInterface: While not directly part of the control system’s logic, the UserInterface object represents the buttons and displays on floors and inside elevators. It interacts with the controller to register requests and display information like floor numbers or out-of-service messages.
SystemAdministrator: This object represents administrative interactions, such as enabling maintenance mode for a specific elevator or triggering emergency operations.
Building: A high-level object representing the structure, which contains a collection of floors and elevators. The Building object may also handle configurations, such as specifying the number of floors, elevators, and operational rules.

Analyze Relationships

ow that we have defined the core objects, it’s time to explore how they interact to form a cohesive system. These relationships are crucial for ensuring the system operates efficiently and meets its requirements.

The Building object serves as the overarching container, holding a collection of Floors and Elevators. It initializes the system with the specified number of floors and elevators and provides a central entry point for the system's operations.

Each Floor interacts with the ElevatorController to register user requests. When a user presses an "up" or "down" button, the request is encapsulated in a Request object and sent to the controller. The controller evaluates all incoming requests, considers the current states of the elevators, and assigns the optimal elevator to service the request.

The ElevatorController communicates directly with the Elevator objects. Once it assigns a request to an elevator, it updates the elevator's target floor and instructs it to move. Elevators report their status (current floor, direction, etc.) back to the controller, ensuring it has up-to-date information to make decisions.

Inside each Elevator, the UserInterface provides controls for passengers. When a user selects a destination floor, the elevator registers it as an internal request. The controller may choose to optimize this by merging the internal request with external ones already in the queue.

The SystemAdministrator interacts with the ElevatorController to trigger operational modes like maintenance or emergency. For instance, in maintenance mode, the controller takes an elevator offline and redistributes requests to the remaining elevators. In an emergency, the controller may override normal operations to prioritize evacuation.

This ecosystem of interactions ensures that requests are handled seamlessly while maintaining flexibility for various operational scenarios.

Establish Hierarchy

To ensure an efficient and reusable design, we’ll abstract shared behaviors and attributes into parent classes or interfaces. This promotes code reuse, adheres to DRY principles, and allows for future extensibility.

Abstract Classes and Interfaces

Entity:

A base class for physical components like Elevator and Floor. It includes common attributes like id (unique identifier) and status (active, maintenance, or emergency).

Requestable:

An interface for objects that generate requests, such as Floor and UserInterface, with methods like generateRequest(direction) and cancelRequest(requestId).

Controller:

A base class for controllers like ElevatorController, with methods to assign requests (assignRequest(request)) and optimize operations (optimizeRoute()).

Specific Classes

Elevator:

Extends Entity, with attributes like currentFloor, direction, and queue (target floors). Includes methods for movement (moveUp(), moveDown()), door control, and handling requests.

Floor:

Extends Entity and implements Requestable. Stores floorNumber and request queues for up and down directions. Generates and clears requests as needed.

ElevatorController:

Extends Controller to manage elevators and assign requests. Attributes include a list of elevators and a priority queue of requests.

Request:

Encapsulates details like originFloor, direction, and priority.

SystemAdministrator:

Provides methods for operational modes, such as setMaintenanceMode() and triggerEmergencyMode().

Design Patterns

Design patterns provide proven solutions to common problems and help structure the system for maintainability and scalability. For the elevator control system, we can apply several patterns to address specific challenges.

Singleton Pattern

The ElevatorController is a central component that coordinates all elevators and requests. Since there should only ever be one controller instance managing the system, the Singleton pattern ensures a single global instance of this class. This prevents conflicts or inconsistencies when multiple components interact with the controller.

class ElevatorController:
    _instance = None

    @staticmethod
    def get_instance():
        if ElevatorController._instance is None:
            ElevatorController._instance = ElevatorController()
        return ElevatorController._instance

Observer Pattern

The system needs real-time updates when elevator or floor states change. For instance, when an elevator reaches a requested floor, the corresponding Floor object should update its state. Implementing the Observer pattern ensures that Floor and Request objects automatically reflect changes from the Elevator or ElevatorController without tight coupling.

class Elevator:
    def __init__(self):
        self.observers = []

    def attach_observer(self, observer):
        self.observers.append(observer)

    def notify_observers(self, event):
        for observer in self.observers:
            observer.update(event)

Strategy Pattern

To optimize elevator movement, the ElevatorController can use different algorithms depending on the situation (e.g., peak hours, off-peak, emergency). By implementing the Strategy pattern, the controller can dynamically switch between strategies like nearest-elevator-first or load-balancing across zones.

class MovementStrategy:
    def execute(self, elevators, request):
        pass

class NearestElevatorStrategy(MovementStrategy):
    def execute(self, elevators, request):
        # Logic for assigning nearest elevator
        pass

class ElevatorController:
    def __init__(self, strategy: MovementStrategy):
        self.strategy = strategy

    def set_strategy(self, strategy: MovementStrategy):
        self.strategy = strategy

    def assign_request(self, request):
        self.strategy.execute(self.elevators, request)

Factory Pattern

For creating different types of requests (e.g., standard or emergency), the Factory pattern simplifies instantiation while ensuring consistency.

class RequestFactory:
    @staticmethod
    def create_request(origin, direction, priority="standard"):
        return Request(origin, direction, priority)

Define Class Members (write code)

Now, we’ll translate the hierarchy and design patterns into code by defining the key attributes and methods for each class. This will provide the foundation for implementing the elevator system.

Core Classes and Attributes

Entity

An abstract base class to define common attributes.

class Entity:
    def __init__(self, entity_id, status="active"):
        self.entity_id = entity_id
        self.status = status

Request

Encapsulates the details of a user request.

class Request:
    def __init__(self, origin_floor, direction, priority="standard"):
        self.origin_floor = origin_floor
        self.direction = direction  # "up" or "down"
        self.priority = priority    # "standard" or "emergency"

Elevator

Represents an individual elevator with attributes like current floor and queue.

class Elevator(Entity):
    def __init__(self, elevator_id, capacity=10):
        super().__init__(elevator_id)
        self.current_floor = 0
        self.direction = "idle"  # "up", "down", or "idle"
        self.queue = []          # List of target floors
        self.capacity = capacity

    def move_up(self):
        self.current_floor += 1

    def move_down(self):
        self.current_floor -= 1

    def add_to_queue(self, floor):
        if floor not in self.queue:
            self.queue.append(floor)

    def open_door(self):
        print(f"Elevator {self.entity_id}: Door opening at floor {self.current_floor}")

    def close_door(self):
        print(f"Elevator {self.entity_id}: Door closing")

Floor

Maintains up and down request queues for each floor.

class Floor(Entity):
    def __init__(self, floor_number):
        super().__init__(f"Floor-{floor_number}")
        self.floor_number = floor_number
        self.up_requests = []    # List of requests going up
        self.down_requests = []  # List of requests going down

    def generate_request(self, direction):
        request = Request(self.floor_number, direction)
        return request

ElevatorController

Central controller for managing all elevators and requests.

class ElevatorController:
    def __init__(self):
        self.elevators = []
        self.requests = []

    def add_elevator(self, elevator):
        self.elevators.append(elevator)

    def assign_request(self, request):
        # Simple nearest-elevator logic for now
        best_elevator = min(
            self.elevators,
            key=lambda e: abs(e.current_floor - request.origin_floor)
        )
        best_elevator.add_to_queue(request.origin_floor)
        print(f"Assigned request at floor {request.origin_floor} to Elevator {best_elevator.entity_id}")

Example flow

# Initialize the system
controller = ElevatorController()
elevator1 = Elevator("E1")
elevator2 = Elevator("E2")
controller.add_elevator(elevator1)
controller.add_elevator(elevator2)

# Generate and assign a request
floor = Floor(3)
request = floor.generate_request(direction="up")
controller.assign_request(request)

# Simulate elevator movement
elevator1.move_up()
elevator1.open_door()

Adhere to SOLID Guidelines

The elevator system design adheres to the principles of SOLID to ensure modularity, maintainability, and scalability.

Single Responsibility Principle (SRP):

Each class has a single, well-defined role:

Elevator manages movement and door operations.
Floor generates and tracks requests.
ElevatorController assigns requests and coordinates elevators.

This separation simplifies maintenance and future updates.

Open/Closed Principle (OCP):

The system is extensible without altering existing code:

New request types can extend the Request class.
Additional movement strategies are easily integrated through the MovementStrategy interface.

Liskov Substitution Principle (LSP):

Subclasses replace their parents seamlessly:

A SmartElevator can override Elevator behavior while maintaining compatibility, supporting polymorphism.

Interface Segregation Principle (ISP):

Classes only implement relevant methods:

Requestable ensures only request-generating components (e.g., Floor) have related methods, avoiding unnecessary dependencies.

Dependency Inversion Principle (DIP):

High-level modules depend on abstractions:

ElevatorController uses MovementStrategy for flexibility in optimization algorithms.
A RequestFactory decouples request creation from other components

Consider Scalability and Flexibility

Scalability

The ElevatorController manages a dynamic list of elevators and floors, enabling effortless scaling.
Optimization algorithms, like zone clustering, can handle larger buildings or peak traffic.

Flexibility

New request types or enhanced elevator behaviors (e.g., SmartElevators) are easy to integrate due to the modular class structure and design patterns.
Components like Request and ElevatorController rely on abstractions, ensuring future upgrades (e.g., AI-based optimization) don’t disrupt existing functionality.

Future-Proofing

The decoupled architecture allows independent upgrades, such as adding IoT integration or advanced dashboards, without impacting the core system.

If this approach looks good, I can proceed to illustrate the architecture with diagrams for better visualization.

Create/Explain your diagram(s)

Class Digram

Workflow Sequence Diagram

This sequence diagram shows how a request is generated and processed.

System Component Diagram

Future improvements

Advanced Optimization

AI-Based Routing: Predict traffic patterns and optimize routes dynamically.
Energy Efficiency: Reduce unnecessary stops and idle times.

Enhanced User Interaction

Mobile Integration: Allow elevator requests via smartphone apps.
Priority Handling: Add VIP or service request options.

IoT and Monitoring

Predictive Maintenance: Use IoT sensors to prevent failures.
Real-Time Dashboards: Provide live elevator status and usage analytics.

Scalability for Large Buildings

Zone-Based Management: Assign elevators to specific building zones.
Express Elevators: Dedicated routes for high-rise structures.