Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Starting with the parking-spots-service ("parking spots service"). The assumed scenario is that a user provides a time window in which they would like to park and we need to respond with a list of available parking spots. The user would then try and make a reservation for one spot for the requested time window.

In any case, the user will choose one or all of: parking lot, time window and we need to make a query to the DB to provide us with a list of spots available in the desired period. The user would then choose the spot/time window combination at which point we would make an entry in the reservations table with a status of "on hold", so no other user can try and book the same slot. After the user completes the payment the status would turn into "reserved".

If the payment doesn't happen within a specified timeout period, the record can be marked as timed-out. When the reservation is put on hold a timer starts, if it times out, the reservation will get a status timed-out and the front end polling mechanism will find it and can tell the user to start all over.

It is possible that a time window is put on hold or reserved by a different user in between the time a user sees it as available and initiates a reservation - in this case we can return an error and a new list of available time windows.

Error handling analysis

1) Double booking: handled by the DB; in case of overlap return error and offer alternative time slots.

2) Payment flow failures:

2.1) callback lost/delayed, a a hold waits forever - there must be a timeout after which the hold is released; the frontend polls so will find that the reservation was canceled; How will the frontend know why? the reservation will have acanceled status, and an error message

2.2) callback is retried (that's what providers do) - it has to be idenpotent, based on a payment id

2.3) user abandons payment - again a timeout after which the reservation entry is deleted.

3) if the payment provider is down - we have timeouts and a circuit breaker

4) database errors

4.1) shard goes down - sharding limits the damage; each has replicas and an in-built failover

4.2) retryable errors - retry with backoff and jitter

Metrics

Utilization rate per lot
No-show rate
Booking conversion
Average reservation duration
Revenue per spot per hour
Standard RED (Rate, Errors, Duration)
Exclusion-constraint conflict rate
Callback delay
Hold expiry rate
Shard hot-spotting
Gate pull query latency

Testing

Security concerns

Payments — card data never enters our systems; the provider returns a token, keeping us out of PCI scope. The /payments/{id}/callback endpoint verifies the provider's signature before any state change, so a forged callback can't confirm an unpaid reservation.
Authorization — every reservation-scoped endpoint enforces ownership (WHERE id = ? AND user_id = ?) to prevent IDOR: user A can't read, cancel, or pay for user B's reservation.
Gate access — QR tokens are cryptographically signed (HMAC), time-bound to the reservation window, and single-use (marked consumed at check-in), so they can't be forged, replayed, or shared.
Data privacy — license plates and visit history are PII (GDPR): encrypted at rest, access-logged, and retained only as long as required. The plate-indexed check-in lookup is a sensitive search surface, so it gets access controls and audit logging.
API hygiene — parameterized queries with strict validation on the time-window inputs (start < end, sane window length), gateway rate limiting against scraping, and admin endpoints behind separate, stronger auth (SSO/mTLS).

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10