Elevator, Floor, Request classes in LLD - System Design Exercise

Design: Elevator Control System

Design the core classes and their interactions for elevator, floor, and request management. Exclude hardware control and detailed UI design.

Functional Requirements

FR1: Manage multiple elevators in a building

FR2: Handle requests from floors to go up or down

FR3: Handle requests from inside elevators to select destination floors

FR4: Optimize elevator movement to reduce wait and travel time

FR5: Track elevator current floor and direction

FR6: Support at least 10 floors and 4 elevators

Non-Functional Requirements

NFR1: Response time for request assignment should be under 200ms

NFR2: System should handle up to 100 concurrent requests

NFR3: Elevator state updates must be consistent and thread-safe

NFR4: Availability target: 99.9% uptime

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Elevator class to track state and handle movement

Floor class to represent each floor and its requests

Request class to represent a pickup or dropoff request

Scheduler or controller to assign requests to elevators

Design Patterns

Observer pattern for elevator state updates

Command pattern for requests

Singleton for central controller

State pattern for elevator movement states

Reference Architecture

  +----------------+       +----------------+       +----------------+
  |     Floor      |<----->|   Controller   |<----->|    Elevator    |
  +----------------+       +----------------+       +----------------+
         ^                         ^   ^                      ^
         |                         |   |                      |
  Floor requests             Assign requests           Elevator state
  (up/down buttons)          (pickup/dropoff)          (current floor,
                                                       direction, requests)

Components

Elevator

Class with attributes and methods

Represents an elevator with current floor, direction, and list of destination requests

Floor

Class with attributes

Represents a floor with up/down request buttons and pending requests

Request

Class

Represents a request either from a floor (pickup) or inside elevator (dropoff)

Controller

Singleton class

Receives requests and assigns them to elevators based on current state

Request Flow

1. User presses up/down button on a Floor, creating a pickup Request

2. Floor notifies Controller of the new Request

3. Controller evaluates all elevators and assigns the Request to the best Elevator

4. Elevator adds the Request to its destination queue

5. Elevator moves floor by floor, updating current floor and direction

6. When Elevator reaches a requested floor, it opens doors and removes the Request

7. Inside Elevator, user selects destination floor, creating a dropoff Request

8. Elevator adds dropoff Request to its queue

Database Schema

Entities: - Elevator(id, current_floor, direction, status, destination_queue) - Floor(number, up_button_pressed, down_button_pressed) - Request(id, type [pickup/dropoff], floor_number, direction [up/down/null], elevator_id [nullable], status) Relationships: - Elevator has many Requests - Floor can have multiple pickup Requests - Requests link to Elevator when assigned

Scaling Discussion

Bottlenecks

Controller becomes a bottleneck when handling many concurrent requests

Elevator state updates may cause race conditions if not synchronized

Request queue management can become complex with many elevators and floors

Solutions

Use concurrent data structures and locks to ensure thread safety

Distribute controller logic or shard by floors or elevator groups

Implement priority queues and efficient scheduling algorithms

Use event-driven architecture to decouple components

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing classes and interactions, 10 minutes discussing scaling and optimizations, 5 minutes summarizing

Clearly define responsibilities of Elevator, Floor, and Request classes

Explain how requests flow through the system and get assigned

Discuss thread safety and state consistency

Mention how to optimize elevator scheduling

Address scaling challenges and solutions

Practice

1. What is the primary role of the Request class in an elevator system?

easy

A. To store the floor number and direction of a user's request

B. To move the elevator between floors

C. To open and close the elevator doors

D. To track the number of elevators in the building

Solution

1. Step 1: Understand the purpose of Request class

   The Request class holds information about where a user wants to go and in which direction.

2. Step 2: Compare roles of other classes

   Elevator moves and Floor represents building levels, but Request stores user input details.

3. Final Answer:

   To store the floor number and direction of a user's request -> Option A

4. Quick Check:

   Request = user floor and direction [OK]

Hint: Request class holds user floor and direction info [OK]

Common Mistakes:

• Confusing Request with Elevator movement
• Thinking Request controls doors
• Mixing Request with Floor class responsibilities

2. Which of the following is the correct way to define a Request class constructor in Python to store floor and direction?

easy

A. def Request(floor, direction): self.floor = floor; self.direction = direction

B. def __init__(self, floor, direction): self.floor = floor; self.direction = direction

C. def __init__(floor, direction): self.floor = floor; self.direction = direction

D. def __init__(self): floor = None; direction = None

Solution

1. Step 1: Recall Python constructor syntax

   Python constructors use def __init__(self, ...) and assign attributes with self.attribute = value.

2. Step 2: Check each option

   def __init__(self, floor, direction): self.floor = floor; self.direction = direction correctly uses self and assigns floor and direction. Others miss self or parameters.

3. Final Answer:

   def __init__(self, floor, direction): self.floor = floor; self.direction = direction -> Option B

4. Quick Check:

   Constructor with self and attributes = def __init__(self, floor, direction): self.floor = floor; self.direction = direction [OK]

Hint: Python constructors need self parameter and attribute assignment [OK]

Common Mistakes:

• Omitting self parameter
• Using class name as constructor
• Not assigning attributes to self

3. Given this Python snippet, what will be printed?

class Request:
    def __init__(self, floor, direction):
        self.floor = floor
        self.direction = direction

r = Request(5, 'up')
print(r.floor, r.direction)

medium

A. Error: missing self

B. floor direction

C. 5 up

D. None None

Solution

1. Step 1: Understand object creation and attribute assignment

   The Request object r is created with floor=5 and direction='up'. These are stored in attributes.

2. Step 2: Print attributes

   Printing r.floor and r.direction outputs 5 and 'up' respectively.

3. Final Answer:

   5 up -> Option C

4. Quick Check:

   Attributes print as assigned = 5 up [OK]

Hint: Print object attributes to see stored values [OK]

Common Mistakes:

• Expecting attribute names instead of values
• Confusing class variables with instance variables
• Assuming error without checking code carefully

4. Identify the error in this Elevator class snippet:

class Elevator:
    def __init__(self, current_floor):
        self.current_floor = current_floor

    def move_to(self, floor):
        current_floor = floor

medium

A. Indentation error in move_to method

B. Missing return statement in move_to method

C. Constructor should not have parameters

D. The move_to method updates a local variable, not the elevator's floor

Solution

1. Step 1: Analyze move_to method

   The method assigns current_floor = floor without self., so it changes a local variable only.

2. Step 2: Understand instance variable update

   To update the elevator's floor, it should be self.current_floor = floor.

3. Final Answer:

   The move_to method updates a local variable, not the elevator's floor -> Option D

4. Quick Check:

   Missing self. means local variable used [OK]

Hint: Use self. to update instance variables inside methods [OK]

Common Mistakes:

• Forgetting self. prefix
• Thinking return is needed to update state
• Assuming indentation is wrong without checking

5. In designing an elevator system with Elevator, Floor, and Request classes, which approach best handles multiple simultaneous requests efficiently?

hard

A. Use a priority queue in Elevator to process requests by nearest floor and direction

B. Process requests in the order they arrive without sorting

C. Assign each request to a random elevator immediately

D. Ignore direction and always move elevators to the highest requested floor first

Solution

1. Step 1: Understand multiple request handling

   Efficient elevator systems prioritize requests to minimize travel and wait time.

2. Step 2: Evaluate options for request processing

   Using a priority queue to pick nearest floors and matching direction optimizes movement. Others cause inefficiency or randomness.

3. Final Answer:

   Use a priority queue in Elevator to process requests by nearest floor and direction -> Option A

4. Quick Check:

   Priority queue for nearest requests = Use a priority queue in Elevator to process requests by nearest floor and direction [OK]

Hint: Prioritize nearest requests with direction for efficient elevator movement [OK]

Common Mistakes:

• Ignoring direction leads to inefficient routes
• Random assignment causes delays
• Processing requests strictly by arrival order wastes time