Problem and Scope
Design a reservation and payment system for a parking garage that allows users to reserve parking spots in advance and pay for them online.
Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.
Requirements to Clarify
A strong answer should establish scope before choosing components.
Functional requirements:
- Users should be able to view available parking spots based on vehicle size
- Users should be able to reserve a specific spot for a specific time duration
- Users should be able to pay for their reservation online
- Users should receive a confirmation or receipt after successful reservation
- Users should be able to cancel reservations if needed
- The system should prevent double-booking of the same spot for overlapping time periods
Non-functional requirements:
- The system should be highly consistent (avoiding double-booking is critical)
- The system should be responsive with minimal latency
- The system should be secure, especially for payment information
- The system should be available 24/7
- The system should be user-friendly and intuitive
Scale and Capacity
Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:
- The system should handle multiple parking garages in different locations
- Each garage may have hundreds to thousands of parking spots
- The system might need to handle peaks during busy hours or events
- Overall throughput is not expected to be extremely high (compared to social media platforms)
Architecture Discussion
Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:
- Database design for storing garage, spot, reservation, and user information
- API design for reservation, payment, and cancellation
- Authentication and authorization mechanisms
- Payment processing integration
- Notification system for confirmations
- System architecture to ensure consistency and availability
- Ensuring no double bookings occur (consistency)
- Handling payment processing securely
- Designing a scalable database schema
- Implementing efficient spot search and filtering
- Managing different types of parking spots (compact, regular, large)
Follow-up Questions
Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:
- How would your design handle the case where two users try to book the same spot at the same time?
- Focus: Assess the candidate's answer to "How would your design handle the case where two users try to book the same spot at the same time" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- Can you elaborate on your database schema design and how it supports the requirements?
- Focus: Assess the candidate's answer to "Can you elaborate on your database schema design and how it supports the requirements" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What trade-offs did you consider when deciding between consistency and availability?
- Focus: Assess the candidate's answer to "What trade-offs did you consider when deciding between consistency and availability" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your system handle payment processing failures or cancellations?
- Focus: Assess the candidate's answer to "How would your system handle payment processing failures or cancellations" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would you scale this system if it needed to support many more garages or higher reservation volume?
- Focus: Assess the candidate's answer to "How would you scale this system if it needed to support many more garages or higher reservation volume" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Evaluation Rubric
MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.
- Requirements and scope (15%): Clarifies and prioritizes the required behavior for Users should be able to view available parking spots based on vehicle size; Users should be able to reserve a specific spot for a specific time duration; Users should be able to pay for their reservation online. Establishes the constraints that materially affect Design a Parking Garage Booking System, including The system should be highly consistent (avoiding double-booking is critical); The system should be responsive with minimal latency. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
- Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Database design for storing garage, spot, reservation, and user information; API design for reservation, payment, and cancellation; Authentication and authorization mechanisms; Payment processing integration. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
- Data and scaling (25%): Uses workload assumptions such as The system should handle multiple parking garages in different locations; Each garage may have hundreds to thousands of parking spots to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Database design for storing garage, spot, reservation, and user information; Designing a scalable database schema; Implementing efficient spot search and filtering. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
- Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for System architecture to ensure consistency and availability; Ensuring no double bookings occur (consistency); The system should be highly consistent (avoiding double-booking is critical). Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
- Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Designing a scalable database schema; Implementing efficient spot search and filtering; Managing different types of parking spots (compact, regular, large). Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.