Getting Ready: Parking Lot System

The Parking Lot is the "Hello World" of Low Level Design problems — and for good reason.

In the real world, parking management is a multi-billion dollar industry. Companies like ParkMobile (processing over 31 million transactions annually), SpotHero, and REEF Technology build sophisticated software systems to manage thousands of parking facilities across cities. Even a modest airport parking structure handles hundreds of vehicles per hour, tracks spot availability across multiple floors, enforces vehicle-type restrictions, and calculates fees using dynamic pricing models.

But the Parking Lot isn't just a real-world system — it's one of the most frequently asked LLD interview questions at companies like Google, Amazon, Microsoft, and Uber. Interviewers love it because:

• It has a natural class hierarchy — vehicles come in different types, spots come in different sizes, and the relationship between them requires careful modeling.
• It involves real OOP relationships — Composition (floors belong to the lot), Association (vehicles occupy spots), and Inheritance (Car, Truck, Motorcycle extend Vehicle).
• It's simple enough to design in 45 minutes, but deep enough to reveal how a candidate thinks about extensibility — what happens when you add electric vehicle charging spots? Or dynamic surge pricing?

This is also the first design problem in our course, which means it serves a dual purpose: you'll practice the entire design process (requirements → UML → code → patterns) while working on a domain that's intuitive and relatable. Everyone has parked a car — so you can focus on the design thinking without getting lost in unfamiliar domain logic.

By completing the Parking Lot design problem, you will:

• Apply the noun-verb extraction technique (Fundamentals S8) to derive classes and methods from plain-English requirements
• Design a Vehicle inheritance hierarchy using abstract classes and polymorphism — your first practical use of the concepts from Fundamentals S3
• Model real OOP relationships — Composition between ParkingLot → Floor → Spot, Association between Spot and Vehicle, Inheritance for Vehicle types
• Draw three UML diagram types — Use Case, Class, and Activity diagrams — applying everything from Fundamentals S5
• Implement the complete system in Python and Java — clean, compilable code organized by logical class groups
• Apply the Strategy Pattern for pluggable pricing models — your first time using a behavioral design pattern (Fundamentals S12) in a real system
• Apply the Factory Pattern for vehicle creation — a creational pattern (Fundamentals S10) that keeps your code open for extension
• Identify edge cases and testing strategies that an interviewer would ask about as follow-up questions

This is the full LLD workflow — the same process you'll use for every design problem in this course and every LLD interview you'll face.

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

• Classes and Objects — creating classes, defining attributes and methods, using constructors (Fundamentals S3)
• Inheritance and Polymorphism — abstract classes, method overriding, compile-time vs runtime polymorphism (Fundamentals S3)
• OOP Relationships — especially Composition (dependent lifecycle) and Association (independent lifecycle). You'll need to decide which relationship type to use and why (Fundamentals S4)
• UML Class Diagrams — how to read and draw class boxes, relationship arrows, and multiplicities (Fundamentals S5)
• SOLID Principles — particularly SRP (Single Responsibility) and OCP (Open/Closed), which will guide our design decisions (Fundamentals S6)
• Strategy Pattern basics — you don't need to be an expert, but understanding that Strategy lets you swap algorithms at runtime will help you appreciate the pricing design (Fundamentals S12)

If any of these feel shaky, revisit the corresponding Fundamentals section first. This design problem applies these concepts — it doesn't re-teach them.

We will design: The core domain logic of a multi-floor parking lot management system — the classes, their relationships, state management for parking spots, vehicle type restrictions, and a pluggable pricing engine. This includes:

• A ParkingLot with multiple Floors, each containing typed ParkingSpots
• A Vehicle hierarchy (Car, Truck, Motorcycle) with type-based spot compatibility
• A Ticket system that tracks entry time and calculates fees on exit
• A pricing engine using the Strategy Pattern (hourly, flat-rate pricing models)
• Spot allocation logic that finds the right spot for the right vehicle

We will NOT design:

• Database schemas — this is object-oriented design, not data modeling
• REST APIs or HTTP endpoints — our system lives at the class level, not the service level
• Payment gateway integration — we calculate fees, but we don't integrate with Stripe or PayPal
• Distributed systems concerns — no load balancing, no database sharding, no microservices
• Frontend/UI — no mobile apps, no display boards, no ticket printers

This boundary is important. In an interview, always clarify scope before designing. A common mistake is drifting into system design (HLD) territory — designing APIs, databases, and infrastructure — when the interviewer asked for LLD. We stay firmly at the class and object level: which classes exist, how they relate, and how they interact through method calls.

Over the next 8 tutorials, we'll follow a systematic design process — the same process you'd use in a 45-minute LLD interview:

1. Requirements — Define what the system must do (functional) and how well it must do it (non-functional)
2. Use Case Diagram — Identify who interacts with the system and what they can do
3. Class Diagram — Design the structural blueprint: classes, attributes, methods, relationships
4. Activity Diagram — Model the workflow for key operations (park/unpark a vehicle)
5. Code Implementation — Write the complete system in Python and Java
6. Design Patterns Applied — Analyze which patterns we used, why, and what alternatives we rejected
7. Testing & Edge Cases — Discuss how to test the design and handle corner cases
8. Summary & Key Takeaways — Recap decisions and prepare for interview follow-ups

This is the 4-Step Framework from Fundamentals S16 (Requirements → UML → Code → Patterns), expanded into a comprehensive design exercise. Let's build a parking lot.