Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
Users should be able to park their car
Users should be able to retrieve their car after it's parked
Users should be able to pay for parking based on the duration
Users can reserve a spot or subscribe to a spot, reservations expire once the time window exceeds
Users can check in at the gate, gate should not let cars in if the lot is full
List the key non-functional requirements (performance, scalability, reliability, etc.)...
Availability over consistency, gate must always be available. Stale admissions (one or two cars enter when gate is full) is allowed
consistency with reserving a parking space, no double-bookings
Low latency, 500ms limit per transaction
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
100M DAU across multiple regions
peak hours would have about 50M requests in a 2 hour window (8am - 10am) , (4pm - 6pm)
about 7000 queries per second at peak time
Scalability: thousands of lots across regions, horizontal scale via partitioning by lot_id, potential sharding by region / id cluster
How much data enters the database per day?
Parking table does not change, Gate table does not change, Reservation table changes
Estimate 10% of DAU reserve
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...
Gate:
GET /gate/space
{
lot_id
type
}
POST /gate/enter
{
lot_id
user_id
type
time
}
POST /gate/exit
{
lot_id
user_id
type
time
}
reject users that haven't paid
Payments
POST /pay
{
lot_id
user_id
type
time // end time
}
Reservation
POST /reserve/park
{
lot_id
type
space_id
time
}
DELETE /reserve/cancel
{
lot_id
type
space_id
time
}
Reserve a parking space
POST /space/park
{
lot_id
type
space_id
}
POST /space/exit
{
lot_id
type
space_id
}
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.
Microservice architecture, each transaction hits a unique service
Load balancer + api gateway before all services, helps maintain requests during high peak situations
Gate - gate service
parking - parking service
reservations - reservation service
payments - payment service
Parking service links to 3rd party payment system / payment api
Gate service hits a cache to reduce the number of queries per second, prevents full lot requests from hitting the main database
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...
SQL, parking spaces can be fairly standardized, also most familiar
Parking table
Gate table
Reservation table
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Gate service is highly available, cache provides faster responses. Trade-off is that sometimes gate can admit cars when the parking lot is full. However, this would only be a few cars at most before the gate table's signal is updated
To ensure consistency, a status is used in the parking table to prevent double bookings. If the status is 'unavailable' booking is prevented