Loading...
The parking lot system is a system that needs the following requirements:
"Your design should accommodate different types of vehicles, prioritize convenience for users, and incorporate features to enhance overall functionality and safety."
Reserve a parking spot — given user, lot, vehicle type, and time window, allocate an available spot with no double-booking.
Payment for reservation — integrate a third-party processor; hold the spot pending payment, finalize on success.
Gate check-in/out — gates record vehicle_arrived / vehicle_left via plate recognition to reconcile actual usage and billing.
No-show handling — free the spot and apply a no-show fee if the vehicle never arrives in the window.
Ability to track current car count in the parking lot
Ability to find the closest available parking location
Tracking car types entering the
indicator that the parking lot is full
No double booking
System should accept
the system should remain open and available, even if the database goes down.
If the database goes down, and can't get resumed, the system retains a current local state of the cars and is able to get updated.
If the dev database is down, reservations can not get submitted due to a case of ACID concerns between the local system and the system in dev.
"It's Monday 8:00am and the reservation service's primary database goes down mid-rush. A car that booked a spot pulls up to the gate, plate gets scanned, but the gate can't reach your service to validate the reservation. What happens at the gate — and what should happen?"
the reservations primary database goes down, meaning there should be a secondary backup database that replicates the primary database in order to ensure high availability. there should be a clear separation of service and database, so if one goes down, then another can take it's place to fill in.
"99.9%+ via multi-AZ replicas; gates fail open"
scalability of the system by lot id
onboarding of lots
List the key non-functional requirements (performance, scalability, reliability, etc.)...
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.