Getting Ready: Car Rental System

Car rental is a $100+ billion global industry. Companies like Enterprise, Hertz, Avis, and Sixt manage fleets of hundreds of thousands of vehicles across thousands of locations. Platforms like Turo disrupt the industry further with peer-to-peer vehicle sharing. Behind every reservation you make on a rental website, there's an object model handling vehicle availability, pricing, insurance bundling, and multi-location pickup/drop-off logistics.

What makes the Car Rental System an excellent medium-difficulty LLD problem is the combination of several distinct design challenges:

• Multi-location fleet management — Vehicles belong to branches, but can be picked up at one location and dropped off at another. This creates a lifecycle where vehicles physically move between inventory pools, and the system must track which vehicles are available where at any given moment.
• Vehicle type hierarchy — The fleet contains sedans, SUVs, trucks, luxury cars, and vans — each with different daily rates, insurance tiers, and capacity attributes. Modeling this cleanly requires a well-designed class hierarchy using inheritance and the Factory Pattern.
• Dynamic pricing — Rates depend on vehicle type, rental duration, season, and demand. Without the Strategy Pattern, pricing logic becomes an unmanageable tangle of conditionals that violates the Open/Closed Principle every time a new pricing model is introduced.
• Insurance and add-on decoration — Renters can add collision damage waivers, liability insurance, GPS devices, child seats, and roadside assistance. Each add-on modifies the base rental cost and terms. This is a textbook application of the Decorator Pattern — layering optional features onto a base rental without changing the core rental class.
• Reservation lifecycle — A rental goes through states: Reserved → Active (picked up) → Completed (returned) → optionally Cancelled. Managing these transitions cleanly requires state-aware design.

This problem appears frequently in LLD interviews at companies like Amazon, Uber, Google, and Booking.com because it tests whether candidates can model a multi-entity, multi-location system with interacting workflows — not just a single-entity CRUD application.

By the end of this design problem, you will be able to:

• Model a multi-location fleet system — design classes where vehicles belong to branches and can be transferred across locations during drop-off
• Design a vehicle type hierarchy — use inheritance and the Factory Pattern to create different vehicle categories (Sedan, SUV, Truck, Luxury, Van) with shared behavior and type-specific attributes
• Implement dynamic pricing — apply the Strategy Pattern to support multiple pricing algorithms (daily rate, weekly discount, seasonal surge) without modifying core rental logic
• Decorate rentals with add-ons — understand how insurance policies and equipment add-ons layer onto a base rental using the Decorator Pattern
• Track vehicle availability across locations — build an inventory system that answers "which sedans are available at the downtown branch next Tuesday?" in real time
• Create two UML diagrams — Use Case Diagram (actor interactions) and Class Diagram (structural blueprint)
• Write complete implementations in Python and Java that match the UML design exactly
• Apply and justify three design patterns — Strategy (pricing), Factory (vehicle creation), and Observer (availability notifications) — explaining why each fits and what alternatives were considered

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition (a Branch composes its vehicle inventory) and Association (a Reservation references a Vehicle and a Customer) — Fundamentals S4
• Inheritance & Polymorphism — the Vehicle hierarchy (Sedan, SUV, Truck) shares common attributes but allows type-specific behavior — Fundamentals S3
• Strategy Pattern — how swappable algorithms avoid pricing if/else chains — Fundamentals S12
• Factory Pattern — how object creation is delegated to a factory instead of littering new calls throughout the codebase — Fundamentals S10
• Observer Pattern — how subjects notify observers of state changes (used for availability updates and reservation confirmations) — Fundamentals S12
• UML Class Diagrams — reading class boxes, relationship arrows, and multiplicities — Fundamentals S5
• UML Use Case Diagrams — reading actors, use cases, and system boundaries — Fundamentals S5

If you've completed the easy design problems (DP1-DP7) and earlier medium problems (DP8-DP11), you already have hands-on experience with Strategy, Factory, and state management. This problem combines them with multi-location complexity.

We will design: The core domain logic of a Car Rental System — vehicle fleet management across multiple branches, customer registration, reservation creation with pickup/drop-off scheduling, pricing calculation via Strategy Pattern, insurance and add-on layering, and vehicle return processing. All modeled as an object-oriented system with clear class hierarchies and design patterns.

We will NOT design: Database schemas, REST API endpoints, distributed systems, web/mobile UI, GPS tracking, payment gateway integration, or loyalty/rewards programs. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

Key distinction from similar problems:

• Unlike the Parking Lot (DP1), which models a single location with spot allocation, the Car Rental System manages fleets across multiple locations with vehicles moving between branches
• Unlike the Hotel Management System (DP14), which focuses on room state management within a single hotel, the Car Rental System focuses on vehicle lifecycle across locations — a vehicle picked up in Manhattan might be dropped off in Brooklyn
• Unlike the Airline Management System (DP28), which schedules fixed routes, the Car Rental System has open-ended return logistics — the vehicle's next location depends entirely on where the customer returns it