Design an Elevator System - Request Feasibility (Single Lift)

Design an intelligent elevator system with feasibility checking and constraint validation.

What is the Elevator System - Request Feasibility Problem?

Design an elevator system for a single elevator that can determine if a new request can be fulfilled given the current elevator state. The system should check feasibility based on capacity constraints, route planning, time estimation, conflict detection, and suggest alternative times if a request is not immediately feasible.

In this problem, you’ll design an intelligent system that validates requests before accepting them, optimizes elevator usage, and prevents overloading through constraint validation and feasibility algorithms.

Problem Overview

Design an elevator system that intelligently checks if requests can be fulfilled before accepting them, considering capacity, route, time, and conflict constraints.

Core Requirements

Functional Requirements:

Feasibility Check: Determine if a new request can be fulfilled given current elevator state (position, direction, load, pending requests).
Capacity Constraints: Check if elevator has sufficient capacity (weight and passenger count) for additional passengers.
Route Planning: Calculate if elevator can reach requested floor without violating constraints or conflicting with existing commitments.
Time Estimation: Estimate time required to fulfill request based on current position, direction, pending requests, and travel time.
Conflict Detection: Detect conflicts between new requests and existing commitments (e.g., opposite direction while committed to current direction).
Alternative Suggestions: Suggest alternative times when request is not immediately feasible, or provide detailed rejection reasons.
Constraint Validation: Validate requests against elevator capabilities (maximum weight, maximum passenger count, floor limits).
Request Types: Handle both internal requests (destination floor selection) and external requests (floor button presses with direction).
Strategy Support: Support different feasibility checking algorithms (strict capacity, optimistic capacity, route-based feasibility) using Strategy Pattern.
Concurrency: Thread-safe operations for simultaneous feasibility checks and request submissions.

Non-Functional Requirements:

Modular Design: Each class should have well-defined roles following the Single Responsibility Principle.
Extensibility: Easy to add new feasibility checking algorithms or modify existing ones without changing core logic.
Thread Safety: Feasibility checking operations must be thread-safe for concurrent requests.
Strategy Pattern: Use Strategy Pattern to allow different feasibility checking algorithms to be swapped at runtime.
State Pattern: Use State Pattern to manage elevator states and their impact on feasibility calculations.
Performance: Feasibility checks should be efficient and provide quick responses to users.

What’s Expected?

1. System Architecture

The system coordinates between users, the feasibility checker, validators, and the elevator, all working together to determine request feasibility.

2. Key Classes to Design

classDiagram
    class ElevatorSystem {
        -Elevator elevator
        -FeasibilityChecker feasibilityChecker
        +checkRequestFeasibility(...) FeasibilityResult
        +requestElevator(...) boolean
    }
    
    class FeasibilityChecker {
        -FeasibilityStrategy strategy
        +checkFeasibility(...) FeasibilityResult
    }
    
    class FeasibilityStrategy {
        <<interface>>
        +checkFeasibility(...) FeasibilityResult
    }
    
    class CapacityValidator {
        <<interface>>
        +hasCapacity(...) boolean
    }
    
    class RoutePlanner {
        <<interface>>
        +canReachFloor(...) boolean
        +calculateRoute(...) List
    }
    
    class TimeEstimator {
        <<interface>>
        +estimateTime(...) long
    }
    
    class ConflictDetector {
        <<interface>>
        +hasConflict(...) boolean
    }

    ElevatorSystem --> FeasibilityChecker
    FeasibilityChecker --> FeasibilityStrategy
    FeasibilityStrategy <|.. StrictFeasibilityStrategy
    FeasibilityStrategy <|.. OptimisticFeasibilityStrategy
    StrictFeasibilityStrategy --> CapacityValidator
    StrictFeasibilityStrategy --> RoutePlanner
    StrictFeasibilityStrategy --> ConflictDetector
    StrictFeasibilityStrategy --> TimeEstimator

System Flow

Feasibility Check Flow

Key Design Challenges

1. Feasibility Checking Strategy

Different scenarios may require different feasibility checking approaches (strict capacity check vs. optimistic assumptions).

Solution: Use the Strategy Pattern. Define FeasibilityStrategy interface with implementations like StrictFeasibilityStrategy (comprehensive checks) and OptimisticFeasibilityStrategy (assumes some passengers might exit). The FeasibilityChecker can swap strategies at runtime without modifying core logic.

2. Capacity Constraint Validation

The system must check if adding new passengers would exceed weight and passenger count limits.

Solution: Implement CapacityValidator interface with DefaultCapacityValidator that compares current load + request load against maximum limits. Check both weight and passenger count constraints before accepting requests.

3. Route Planning and Time Estimation

The system needs to calculate if the elevator can reach the requested floor and estimate how long it will take.

Solution: Implement RoutePlanner to calculate route considering current position, direction, and pending requests. Implement TimeEstimator that calculates time based on route, travel time per floor (2 seconds), and door operations (3 seconds per stop).

4. Conflict Detection

The system must detect if a new request conflicts with existing commitments (e.g., opposite direction while committed to current direction).

Solution: Implement ConflictDetector that checks if requests require opposite directions while elevator is committed to current direction. Consider pending requests that commit the elevator to continue in current direction.

5. Alternative Time Suggestions

When a request is not immediately feasible, the system should suggest when it might become feasible.

Solution: Calculate alternative times based on estimated completion of current requests. Provide multiple alternatives (e.g., current estimated time, +30s, +60s) to help users make informed decisions.

What You’ll Learn

By solving this problem, you’ll master:

✅ Strategy Pattern - Swappable algorithms for feasibility checking.
✅ State Pattern - State-specific behavior affecting feasibility calculations.
✅ Algorithm Design - Route planning, time estimation, and conflict detection.
✅ Constraint Validation - Capacity limits, floor limits, and route feasibility.
✅ Concurrency - Thread-safe feasibility checks and request submissions.

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 - Request Feasibility, try these similar problems:

Elevator System - Multiple Lifts - Multiple elevator coordination.
Elevator System - Single Lift - Basic single elevator system.
Rate Limiter - Constraint validation and feasibility checking.