Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

1) there would be different charges for different vehicles (motorcycle, car, bus, EV )

2) when a vehicle enters they are assigned a spot and a ticket is generated

3) User should be able to reserve a spot in advance

• if the user is late after a 15 minutes grace the reservation is cancelled and we free up the spot.

4) We should know if there are enough space available else need to display full, digital display boards at entrance/per-floor

5) payment would on timely basis

6) on vehicle exit the bill is calculated and the spot is freed.

7) if a ticket is lost full max fee is charged

8) special spots EV charging spots or handicapped spots

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

1) Spot allocation should be instant (under 1000ms) when the vehicle is scanned at the gate.

2) No same spot can be shared between two cars so concurrency is important

3) New vehicle types should be added easily and prices can be altered

System should be highly available and consistent, should be able to support across 1000s of lots across various regions.

display available spot count" across a dashboard, eventual consistency might be fine.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

How many parking lots?

-> 5000

Average spots per lot?

-> 500

Average stay time of vehicle

-> 2 hours

Open time

-> 16 hours a day

So basically each spot has been used twice a day

So Turnover rate = 8 times a day

Total spots = 5000 × 500

so we are talking around 2.5M spots

Daily vehicle entries = total spots × turnover/day

Assuming we use 50% capacity on an average all the time

which means 1-1.25M spots are used

Daily throughput then would be x8 around 10M

Entry QPS

1,0000,000 ÷ 86,400 seconds

120 QPS

Double the qps for peak which sits at 240 QPS

Storage estimation

A ticket/record: vehicle plate, entry time, exit time, spot ID, fee, payment status — maybe ~200 bytes - 1KB per record.

Around 10M daily entries a day

About 365 GB per year (10M × 365 × 1 KB).

• Per day: 10M × 1 KB = 10 GB
• Per year: 3650 GB (decimal), or roughly 3480 GiB if 1 KB = 1,024 bytes
• In TB: about 3 TB

~10-15 TB/year including replication overhead

API Design

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...

High-Level Design

A Client / Edge device (a driver's app, or the gate's ANPR camera and controller) sends a request to a Load Balancer, which spreads traffic across instances of the API Gateway. The gateway routes each request into the MicroServices boundary, which holds five services: Reservation, Ticket, Parking, Payments, and User.

What the services talk to

• Redis (two-way): services read availability counts and cached data from Redis, and write updates back to it. This is your read path for the 12,000 peak QPS of "is there space?" checks.
• Database (direct arrow, labeled "Locking to avoid duplicate in DB"): services write to the database directly, and locking there is what stops two cars from getting the same spot. The databases are drawn as four stacked instances labeled "Partitioned by Lots", so each lot's data lives on one shard.
• Queue → Notification (async): services publish events to a queue, and the Notification service consumes them to send messages to users.
• Payment Gateway (external): the Payments service calls it for actual charges.
• S3 object storage: holds the ANPR images, so they stay out of the main database.
• External Config (arrow up): services read things like pricing and vehicle types without a redeploy.
• Scheduler (two-way): the Reservation side registers timers, and the scheduler calls back when one fires, for example to cancel a reservation after the 15-minute grace period.

Reserve journey, end to end

1. Search and capacity check. The driver's app calls the API Gateway, which routes to Parking. Parking reads the availability count from Redis. If it's zero, the app shows "full" and the flow stops. This is the cheap, high-volume read path, and it's only a hint, not a guarantee.
2. Hold the spot. The app calls Reservation, which opens a DB transaction on the lot's shard and runs SELECT ... FOR UPDATE SKIP LOCKED on a free spot of the right type (EV, handicapped, and so on). It marks the spot HELD, inserts a reservation with status PENDING_PAYMENT, and commits. The database is the source of truth here, so this step prevents double-booking.
3. Update the cache and set timers. After the commit, Reservation decrements the Redis counter and registers two timers with the Scheduler: a short payment window (say 10 minutes) and the 15-minute arrival grace period.
4. Pay. Reservation asks Payments to charge. Payments reads the price from External Config and calls the external Payment Gateway, passing an idempotency key so a retry never double-charges.
5. Confirm. When payment succeeds, Reservation flips to CONFIRMED, and an event goes onto the Queue so Notification sends the confirmation.
6. Arrival. At the gate, the ANPR camera sends the plate to Ticket, which matches it to the reservation, issues the ticket, and marks the spot OCCUPIED.

Ownership summary: Parking owns reads, Reservation owns the hold and its state, Payments owns money, Ticket owns entry and exit, and Notification owns messaging.

Payment handoff and callback

The outbound call alone leaves the reservation stuck in PENDING_PAYMENT if the response is lost. Close the loop three ways:

• Webhook (primary). The gateway calls back into your system through the API Gateway to Payments. Payments verifies the signature, records the result idempotently (the same webhook can arrive twice), and publishes PaymentSucceeded or PaymentFailed to the Queue. Reservation consumes the event and updates its status.

Database Design

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...

Detailed Component Design

q. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

1. Spot allocation

• The DB is the source of truth, partitioned by lot_id so allocation is a single-shard transaction.
• Use SELECT ... FOR UPDATE SKIP LOCKED on a free spot, so concurrent gates lock different rows and never double-book.
• Best-fit spot choice (smallest compatible type, nearest to the entrance).
• If the DB is down, the gate falls back to an offline ticket and syncs later.

2. Availability (Redis)

• One counter per lot and spot type, updated after each DB commit.
• It's only a hint. The DB decides, and a periodic job reconciles drift.
• This is what absorbs the 12k read QPS.
• If Redis dies, fall back to the DB.

3. Reservation lifecycle

• State machine: PENDING_PAYMENT → CONFIRMED → CHECKED_IN → COMPLETED, plus EXPIRED and CANCELLED.
• Transitions are conditional updates, so duplicate webhooks and timers are harmless.
• The Scheduler (Redis sorted set or delayed queue) handles the payment window and the 15-min grace.
• If a webhook is lost, the timer triggers a status check with the gateway.