Parking reservation - a spot is a time slot with a location

Why this design

Parking reservation is the booking problem with arbitrary time ranges instead of nights, and with an inventory that physically refuses to free itself on time. Interviewers use it to see whether you can prevent overlapping bookings without a race (and know why "check for overlaps, then insert" is one), how you turn a pool of interchangeable spaces into something a constraint can protect, and what you do when the car does not leave.

What you will learn

• Why a booking is a range, not exploded slots, and how an exclusion constraint makes overlaps impossible rather than unlikely.
• Why a garage is split into virtual bays, so an at-most-one constraint can protect a 400-space pool.
• Why a turnover buffer is part of the range the constraint compares.
• Why 6% of every garage is never sold, and what that reserve is for.
• Why the gate count beats the reservation table about how many cars are inside.
• Why overstays are correlated, which is the failure the reserve cannot absorb.

How to read this board

1. Press play once: the walkthrough follows one car from search to the minute it does not leave.
2. BOOK: search, availability, the bay assignment and the constraint.
3. ARRIVE: the gate, plate reads and live occupancy.
4. OVERSTAY: detection, re-seating the next driver, billing.
5. DATA MODEL: bays, reservations as ranges, and gate events.
6. Then pages 1 to 6 in order: requirements, capacity, storage, availability, how it works, deployment.

A driver wants a guaranteed space near a place for a window of time. A garage operator wants every space earning. The system sits between a promise and a car park.

Ask these before designing

• Is a booking for a specific spot or any spot in a garage? Garages are usually pooled (any space on the level); driveways and marked bays are specific. This board models both as bays.
• What granularity? 15 minutes is standard. Arbitrary ranges at that granularity are why the board keeps ranges rather than slots.
• Is there a gap between bookings? A turnover buffer of 10-15 minutes, so the next driver does not arrive to find the last one reversing out.
• How is arrival detected? Plate recognition (ANPR) at the gate, a QR code, or an app check-in. ANPR is frictionless and wrong about 5% of the time on the first read.
• What happens on overstay? Grace period, then per-15-minute charge - and what happens to the driver booked next?

Functional

• Search garages near a point for a time window, with price and walking distance.
• Book a window; get a guaranteed space or a clear refusal.
• Enter and exit by plate recognition, with a QR fallback.
• Extend a booking from the app if the bay is free afterwards.
• Detect overstays, notify, and charge per started 15 minutes past the grace period.
• Re-seat or refund the next driver when an overstay blocks them.

Non-functional

• No double booking in the ledger, ever - enforced by the database.
• Booking p99 under 500 ms, including during event on-sales at 2,000 bookings/minute for one venue.
• Gate open p95 under 1.5 s from the car stopping at the barrier. A queue at a barrier is a traffic problem on a public road.
• Gate works offline. It must admit valid bookings with the backend unreachable.
• Overstay detection within 2 minutes of end plus grace.

Out of scope

Dynamic pricing, EV charging sessions, monthly permits, enforcement on street parking, operator payouts.