Design a Parking Lot Management System's Object Model with Evolving Requirements

Design the object model for a parking lot management system: the main classes and interfaces, what each is responsible for, how they relate, and the code-level flow when a vehicle arrives, parks and later leaves. This is a low-level design round, so the interviewer expects class and method signatures and the reasoning behind them rather than a distributed architecture. Expect the requirements to move during the discussion. After you present a first version, the interviewer adds rules and edge cases, and the round rewards a design that absorbs those changes with small, local edits, together with clear justification of each structural choice in terms of design principles. ### Constraints and Clarifications For a first version, assume the following and confirm it with the interviewer: - One building with several levels, several entry gates and several exit gates. - Spots come in a few sizes (for example small, regular and large), and each vehicle type may use only certain sizes. - A ticket is issued at entry, and the fee is computed at exit from the time parked. - The system runs as one service that keeps live state in memory and can persist it; managing several sites is not needed yet. ### Clarifying Questions - Which vehicle types must be supported, and which spot sizes may each use? - Does the system assign a spot at the gate, or does the driver pick one? - How is the fee calculated: per started hour, a flat daily rate, different rates by vehicle type or by time of week? - How do drivers pay: at the exit gate, at kiosks, or through an app? - What should happen when a driver loses the ticket? ### Part 1 — Core model and the park and leave flows Identify the classes and enums, their key fields and methods, and show how a vehicle is admitted (spot chosen, ticket issued) and how it checks out (fee computed, payment taken, spot released). ```hint Find the seams first List the rules most likely to change (which spot to pick, how much to charge, which vehicle fits which spot) and give each its own home instead of burying it inside the lot class. ``` #### What This Part Should Cover - A small set of classes with single, clear responsibilities and explicit relationships - Admit and checkout flows that keep the lot's state consistent - Spot lookup that does not scan every spot on each arrival - Money handled exactly, without floating-point arithmetic ### Part 2 — Absorbing new requirements Extend the design for three representative changes an interviewer might introduce: some spots get electric-vehicle chargers and charging is billed separately; rates differ by vehicle type and are higher at weekends; and the lot should assign the free spot nearest to the gate a vehicle entered through. For each change, show which classes are added and which existing classes must change. ```hint Count the edits For each new rule, list the existing classes you would have to open and modify. If the lot or ticket class changes every time, a responsibility is in the wrong place. ``` #### What This Part Should Cover - Extensions added mostly as new implementations rather than edits to existing classes - Pricing rules that compose without a growing chain of conditionals - A nearest-spot rule that uses gate-to-spot distances efficiently - An honest account of which changes do require edits, and why ### Part 3 — Concurrency and edge cases Two vehicles can arrive at different gates at the same instant when only one suitable spot is left. Explain how the design guarantees they are not both given that spot, and how it handles a full lot, a lost ticket, a failed payment at the exit, the same plate entering twice, and a spot taken out of service. ```hint Two gates, one spot Decide exactly which check and which update must happen as one indivisible step, and which object owns the lock or atomic operation that guarantees it. ``` #### What This Part Should Cover - A precise atomicity boundary for claiming a spot, and its throughput cost - How the guarantee carries over when state lives in a database instead of memory - Specific handling for each listed edge case ### What a Strong Answer Covers - Responsibilities split so that each likely change touches one place - Design principles (single responsibility, open for extension, depending on abstractions) used to justify decisions, not just named - Correct state transitions for spots and tickets, including failure paths - A concrete concurrency story rather than "add a lock somewhere" - Calm, incremental adaptation as the interviewer changes the requirements ### Follow-up Questions - How would the design change if one service managed many lots and a mobile app showed live availability? - How would you add reservations for a future time window without overbooking? - How would you persist state so a service restart does not lose who is parked where? - How would you unit-test the pricing and spot-allocation rules in isolation from the rest of the system?