Loading...
High availability — if the system goes down, gates can't open and users can't access their reservations
Low latency — spot availability checks and gate check-ins need to happen in under 200ms
Consistency — payment and reservation status must be strongly consistent, we can't double-book a spot
Durability — reservations and payment records can never be lost
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...
POST /reservations
input: { spot_id, user_id, start_time, end_time }
output: { reservation_id, status: "reserved" }
POST /reservations/:reservation_id/payment
input: { payment_method }
output: { payment_status, receipt_id }
POST /gate/checkin
input: { reservation_id }
output: { status: "occupied", spot_id }
POST /gate/checkout
input: { reservation_id }
output: { status: "available", final_charge }
PUT /reservations/:reservation_id/cancel
input: { reservation_id }
output: { status: "available", refund_status }
GET /spots
input: { lot_id, time_range }
output: { list of available spots }
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.
"The system starts with the client hitting the API gateway which handles authentication and rate limiting. The load balancer then routes requests to one of four microservices — reservation service, payment service, gate service, or notification service. The reservation service checks the cache first for spot availability before hitting the database. The payment service calls out to Stripe externally and updates the database on success. The gate service verifies reservations on check-in and closes them out on checkout, updating spot status in the database. The notification service sends confirmation emails and alerts asynchronously. A background scheduler runs every few minutes independently, checks for expired reservations with no check-in, flips those spots back to available, and triggers the notification service. All writes go to the primary database which replicates to a secondary for redundancy."
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.
"The reservation service is the core of the system. When a user books a spot, it first checks Redis cache for current availability — since spot lookups are read-heavy, caching dramatically reduces database load. On a cache miss it queries the database, returns available spots, and populates the cache. When a reservation is confirmed it updates the spot status from available to reserved in the database and invalidates the cache entry for that spot.
The payment service never handles card data directly — it calls Stripe's API with the charge amount and gets back a success or failure. On success it updates the reservation status to paid in the database. This keeps the system PCI compliant since sensitive payment data never touches our servers.
The scheduler is a background cron job that runs every 5 minutes. It queries the database for any reservations where status is reserved, the start time has passed, and no check-in has been recorded. It flips those spots back to available and publishes a no-show event to the notification service. No user triggers this — it runs entirely on its own."