Read the problem statement carefully. Identify the core objective, the actors involved, the mandatory features, and anything that needs clarification. Use a top-down approach: establish the scope first, then work through one requirement at a time.

What to do

• Highlight the important features and business rules.
• Ask clarifying questions instead of silently assuming requirements.
• Write down assumptions so the interviewer can validate them.
• Separate essential functionality from optional enhancements.

Questions to ask yourself

• Who will use the system?
• What are the primary inputs and outputs?
• Which rules are fixed, and which may change?
• What is outside the scope of this design?

Translate requirements into system behaviours. Prioritize the most important functionality and implement one feature at a time. Before writing a major function, be clear about what it does.

Parking-lot functionality

• Register vehicle entry and issue a parking ticket.
• Find an eligible available spot and assign it to the vehicle.
• Calculate parking fees based on the applicable pricing rules.
• Accept payment and update the ticket’s payment status.
• Release the parking spot when the vehicle exits.
• Update the availability displayed to users.

Choose appropriate data structures and algorithms for the operations that matter. For example, repeatedly scanning every parking spot may become inefficient as the lot grows.

Think beyond the happy path. Identify what can fail, how the system should respond, and how to prevent invalid state changes.

Parking-lot edge cases

• The parking lot is full and no eligible spot is available.
• A vehicle type is incompatible with the selected spot.
• A customer attempts to pay twice for the same ticket.
• A payment fails or the payment provider times out.
• An electric charging spot is already occupied.
• Two entry requests attempt to reserve the same spot simultaneously.
• A ticket has expired or has already been closed.

How to reason about these cases

• Validation: Check vehicle type, ticket state, and payment amount.
• Error handling: Return clear errors and handle recoverable failures appropriately.
• Concurrency: Make spot reservation and state changes atomic where required.
• Security: Validate permissions and protect sensitive information.
• Performance: Identify bottlenecks, avoid unnecessary repeated searches, and choose suitable data structures.

Convert the requirements into a domain model. Identify the main entities, their data, their behaviour, and how they relate to one another. Draw a rough class diagram after the responsibilities become clear.

Possible parking-lot classes

Understand relationships

• One-to-many: A parking lot can contain multiple floors.
• One-to-many: A floor can contain multiple parking spots.
• Association: A ticket connects a vehicle to its parking session and assigned spot.
• Composition: Consider it when one object’s lifecycle is tied to another object’s lifecycle.
• Inheritance and interfaces: Use them when the domain genuinely benefits from substitutable types or shared contracts.

Once the requirements and responsibilities are clear, map each important user journey. Determine which object initiates an operation, which object performs it, and what state changes occur.

Example: vehicle entry

Example: vehicle exit

A sequence diagram can help explain the interactions between an entry panel, parking service, spot allocator, ticket service, payment service, and exit panel. Keep the diagram focused on the use case being discussed.

Decide what information must persist and how it relates. In an LLD interview, the depth of database design should match the requirements and available time.

Possible entities or tables

• ParkingLot and ParkingFloor
• ParkingSpot and Vehicle
• Ticket and Payment

Design considerations

• Define primary keys, foreign keys, and entity relationships.
• Normalize data where appropriate to avoid unnecessary duplication.
• Use indexes that support important queries, such as finding available spots.
• Define constraints that prevent invalid relationships and states.
• Consider transactions when multiple changes must succeed together.
• Discuss partitioning, replication, or sharding only if scale requirements justify them.

Identify the operations needed by the system’s clients. Define their inputs, outputs, validation rules, and failure responses. For a class-level design, these interfaces may be methods; for a service, they may be HTTP endpoints.

Illustrative REST endpoints

What to define

• Request and response structures.
• Input validation and consistent error responses.
• Authentication and authorization where applicable.
• Idempotency for operations where retries could cause duplicate effects.
• Clear separation between API controllers and business logic.

These endpoints are illustrative design examples, not a claim about the current implementation of a real parking system.

Consider design patterns after you understand the requirements and object responsibilities. A pattern should make the design easier to maintain or extend—not simply make it more elaborate.

Use the class diagram to summarize the classes, their important attributes and methods, and the relationships between them. It should reflect the design you have reasoned through, not replace that reasoning.

Include the essentials

• Core classes and their key responsibilities.
• Important attributes and public operations.
• Associations and meaningful multiplicities, such as one-to-many.
• Inheritance or interface implementation where relevant.
• Dependencies that clarify how responsibilities are separated.

For the parking-lot example, show how ParkingLot, Floor, ParkingSpot, Vehicle, Ticket, and Payment connect. Keep the diagram readable and explain any non-obvious relationship.

Document the important assumptions and explain why the design works for the stated requirements. In an interview, concise verbal documentation can be enough; for a real project, record the decisions that other developers need to understand.

• Requirements and assumptions.
• Class responsibilities and key interactions.
• Chosen design patterns and why they are appropriate.
• Important validation and error-handling rules.
• Known limitations and possible future improvements.

Explain the design before coding, then implement the most important functionality in a logical order. Keep the interviewer informed about your decisions instead of silently writing code.

One possible project structure

For a service-oriented implementation, a typical flow is controller → service → repository. Keep business rules in appropriate domain or service components rather than scattering them across controllers.

Principles to keep in mind

• OOP: Encapsulation, abstraction, inheritance, and polymorphism.
• SOLID: Design for clear responsibilities and manageable dependencies.
• KISS: Keep the solution as simple as the requirements allow.
• DRY: Avoid unnecessary duplication.
• YAGNI: Don’t implement speculative features prematurely.
• SoC: Separate concerns that change for different reasons.
• Use meaningful names, useful comments, and appropriate logging.
• Prefer composition over inheritance when it better represents the relationship.

Test the important behaviours of each component. Focus on correctness, boundary conditions, and the rules that protect the system from invalid states.

Parking-lot test scenarios

• A compatible vehicle is assigned an available spot.
• No spot is assigned when the lot is full.
• An incompatible vehicle cannot occupy a spot.
• Fee calculation returns the expected result for a known duration.
• A failed payment does not incorrectly mark a ticket as paid.
• A successful exit releases the spot and updates the session state.
• Repeated payment or exit requests are handled safely.

Start with one or two meaningful tests for each major operation where time is limited. Use unit tests for isolated logic and integration tests where multiple components must work together.

Finish by reviewing the design against the requirements. Look for unnecessary complexity, missing edge cases, poor separation of concerns, and opportunities to make the solution easier to test or extend.

Review questions

• Does the implementation cover all mandatory functionality?
• Are classes cohesive and responsibilities appropriately separated?
• Are interfaces and abstractions justified by real requirements?
• Are error cases and state transitions handled correctly?
• Are the algorithms and data structures suitable for the workload?
• Can storage be replaced or extended without rewriting unrelated logic?
• Can new spot types or pricing rules be introduced with limited changes?
• What would you improve if you had more time?