Case Study: Parking Lot System Design

The Parking Lot System stands as the quintessential low-level design problem—a deceptively simple domain that reveals whether a candidate truly understands object-oriented design, pattern application, and systematic problem-solving. It appears in technical interviews at companies like Google, Amazon, Microsoft, and countless startups not because parking lots are particularly exciting, but because the problem domain is universally understood while offering remarkable depth for design exploration.

Why requirements analysis comes first:

Before drawing a single class diagram or writing a line of code, elite engineers invest substantial effort in understanding what they're building. This isn't bureaucratic overhead—it's the difference between a design that elegantly solves the right problem and one that perfectly solves the wrong problem.

In this page, we'll systematically analyze the parking lot domain, extract functional and non-functional requirements, and establish the foundation upon which our entire design will rest.

A parking lot, at its most fundamental level, is a facility where vehicles are temporarily stored for a fee. But this simple definition conceals remarkable complexity. Before we can design a system, we must develop deep domain understanding.

The physical reality:

A real parking lot is a spatial entity with physical constraints. It has a finite number of spaces, organized across potentially multiple floors or sections. Different spaces accommodate different vehicle types—a motorcycle spot cannot fit a truck, and an electric vehicle charging space serves a specialized purpose. Entry and exit points control traffic flow, and the physical layout determines which spots are accessible when.

The operational reality:

Beyond the physical, parking lots are businesses with operational concerns. They need to track occupancy in real-time, calculate fees based on duration and vehicle type, issue and validate tickets, handle payment processing, and generate reports for management. Peak hours demand efficient allocation, while off-peak periods might enable flexible pricing strategies.

In an interview or real-world scenario, requirements are never handed to you on a silver platter. The ability to ask incisive clarifying questions separates exceptional engineers from those who make dangerous assumptions.

The meta-skill of question-asking:

Good questions serve multiple purposes: they reveal hidden complexity, they demonstrate your systematic thinking, they give you control over the problem's scope, and they build rapport with the interviewer. The goal isn't to ask every possible question—it's to ask the right questions that disambiguate critical design decisions.

Sample interview dialogue:

You: "Before I start designing, I'd like to understand the scope. Should I design for a single parking lot or a system managing multiple lots?"

Interviewer: "Let's focus on a single lot for now, but design it so we could extend to multiple lots."

You: "Great. What vehicle types should we support?"

Interviewer: "Motorcycles, cars, and larger vehicles like buses."

You: "Should a motorcycle be able to park in a car spot if all motorcycle spots are full?"

Interviewer: "Interesting question. Let's say yes, but we should prefer motorcycle spots for motorcycles."

You: "For pricing, is this hourly, daily, or both? And does it vary by vehicle type?"

Interviewer: "Hourly for now, with different rates per vehicle type."

Notice how each question narrows the design space and reveals requirements that weren't initially stated. The interviewer's responses become your documented requirements.

Functional requirements describe what the system must do—the behaviors and features users directly experience. After our clarifying conversation, we can document these with precision.

The difference between good and great requirements:

A novice might write: "The system should park cars." This is a starting point, but it leaves too much ambiguity. Great requirements are testable—you can objectively verify whether the system satisfies them. They specify the actor, the action, and the expected outcome.

Organizing requirements by actor:

Another powerful technique is grouping requirements by who initiates them:

Non-functional requirements (NFRs) describe how the system should behave—the quality attributes that cut across all features. While often overlooked in LLD discussions, NFRs profoundly influence design decisions.

Why NFRs matter for LLD:

Consider a parking lot with a single entry point versus one with ten simultaneous entry points. The functional requirements might be identical, but the concurrency NFR drives you toward thread-safe data structures, perhaps even a different architectural approach entirely. NFRs are the invisible forces shaping your design.

Use cases describe end-to-end scenarios from the user's perspective. They're more narrative than requirements lists and help verify that your design covers complete workflows.

The primary use cases:

Deriving methods from use cases:

Each step in a use case often maps to a method or responsibility in your design:

This traceability from use case to class responsibility is what distinguishes ad-hoc design from systematic engineering.

Every design exists within constraints and is built upon assumptions. Making these explicit prevents misunderstandings and documents the boundaries of your design.

Before moving to entity identification, let's preview how our requirements will drive design decisions. This forward-looking analysis demonstrates the systematic thinking interviewers value.

This traceability matrix serves multiple purposes:

1. Justification: Every design choice ties back to a requirement
2. Completeness Check: Ensure every requirement has coverage
3. Interview Communication: Explain why you chose specific patterns
4. Maintenance: When requirements change, you know which design elements are affected

The insight to internalize:

Patterns like Strategy and Factory aren't decorative—they're the natural solution to requirements demanding flexibility and extensibility. When someone asks "Why did you use Factory here?", the answer isn't "Because it's a common pattern." The answer is "Because FR-1 requires multiple vehicle types, NFR-4 requires extensibility, and Factory gives us both while keeping creation logic centralized."

We've completed the most critical phase of the design process—understanding what we're building before we build it.

What's next:

With requirements in hand, we're ready to identify the core entities that will form the backbone of our design. In the next page, we'll systematically extract Vehicle, ParkingSpot, Ticket, and ParkingLot—defining their attributes, behaviors, and responsibilities.