Parking Lot System Design

Introduction

This problem rewards one habit: state your invariants before you draw boxes.

If you start with “I’ll create classes: ParkingLot, Floor, Spot…” you’ll drift into a pretty diagram that doesn’t answer the real question: how does the system stay correct when 3 cars arrive at once and the gate controller retries requests?

For a new engineer, parking lot teaches how to move from requirements → rules → invariants → model → API → concurrency. For a senior engineer, it’s a chance to show operational thinking: the world is messy, events are duplicated, devices go offline, and “available spots” is a product surface that can be approximate—but spot assignment cannot.

How to approach

Use this order in the room.

1. Lock down the rules (5 minutes).

   • Vehicle types: motorcycle, car, truck.
   • Spot types: compact, regular, large (plus optional accessible/EV).
   • Compatibility: decide it explicitly.
   • Allocation policy: “nearest” (to which entrance?), “any on lowest floor”, or “zone-based”.
   • Payment: on exit, on entry, or mixed? Any grace period?
   • Are reservations allowed? Are attendants allowed to override?

2. Define the invariants (30 seconds, but do it).

   • Spot has at most one active occupancy.
   • Ticket/session has a single lifecycle (OPEN → PAID → CLOSED).
   • Payment is idempotent and reconciled.

3. Walk one entry + one exit end-to-end.

   • Entry: allocate spot atomically, create session, return ticket.
   • Exit: compute fee, pay idempotently, release spot once.

4. Then talk about performance and “real-time” availability.

   • Fast reads with cached counts.
   • Correct allocation with a transactional source of truth.

If you do those four steps, your design will feel intentional.

Interview tips

• When you say “nearest spot,” define what “nearest” means. Nearest by floor number? By walking distance from a specific entrance? By “same zone”?
• Make one explicit decision about source of truth: availability counts can be cached, but spot occupancy state must be durable.
• When the interviewer asks about concurrency, do not say “we use a lock” generically. Say what is locked (spot row, floor pool, or “active session by vehicle id”) and how retries behave (idempotency key).
• Pricing is a trap: define rounding (per minute? hourly?), grace periods, and “lost ticket” handling.

Capacity estimation

Given the prompt numbers:

Input	Estimate	Why it matters
Vehicles per day	~2000	Writes are moderate; correctness beats throughput.
Peak arrival rate	~5/min	Concurrency exists, but not “internet scale.” Still enough to double-assign without atomicity.
Spots	~1000	A single database can handle it; the design focus is modeling + invariants.
Availability reads	High	Displays + apps read often; caching counts matters more than optimizing entry QPS.

Implication: Your backend can be simple and still be impressive—if the invariants and lifecycle are crisp.

High-level architecture

The physical world produces events; your backend enforces state transitions.

[ Gate / Sensor ] → [ Entry/Exit API ] → [ Parking service ] → [ DB (truth) ]
                           |                    |
                           |                    → [ Cache / counters (fast reads) ]
                           |
                           → [ Payments provider ] → [ Payment records ]

Key split: allocation happens against the DB in a transaction; availability can be served from counters that are eventually consistent.

Data model (entities + invariants)

You don’t need a giant ERD—just enough to encode correctness.

Core entities

• ParkingLot: metadata (name, address), configuration (policies, pricing rules).
• Floor: id, level number, zones.
• Spot: spot_id, floor_id, type (compact/regular/large), status (AVAILABLE/OCCUPIED/OUT_OF_SERVICE), optional features (EV, accessible).
• Vehicle: vehicle_id (or plate), type.
• ParkingSession (ticket): session_id, vehicle_id, spot_id, entry_time, exit_time?, status (OPEN/PAID/CLOSED), created_by (gate vs attendant), version.
• Payment: payment_id, session_id, amount, currency, status, provider refs, idempotency_key.

Invariants to enforce

1. One active session per spot.
2. One active session per vehicle (optional, but usually intended).
3. Session lifecycle is monotonic: OPEN → PAID → CLOSED (no skipping backwards).
4. Payment idempotency: the same “pay” request cannot double-charge.

The rest of the “OO design” flows naturally once these are clear.

Detailed design

Compatibility rules (make them explicit)

One simple policy:

• Motorcycle → any spot (compact/regular/large)
• Car → regular or large
• Truck → large only

Then layer policy rules:

• Accessible spots require driverHasPermit=true
• EV spots require vehicle.isEV=true (or allow non-EV at high occupancy with an explicit policy)

The key is separating physical fit from policy eligibility.

Entry flow (allocate spot)

Goal: allocate one compatible spot atomically and return a ticket.

1. Request: vehicle type + optional preferences (floor, zone, accessible, EV).
2. Parking service selects candidate set (by policy).
3. Atomically claim one spot and create a session.
4. Return { session_id, spot_id, floor, instructions }.

Atomic claim can be done in multiple ways; pick one and defend it.

Option A: transaction on spot row (simple and strong).

• Query candidate spot ids (bounded).
• SELECT spot WHERE status=AVAILABLE ... FOR UPDATE SKIP LOCKED (or equivalent).
• Update spot to OCCUPIED.
• Insert ParkingSession with status OPEN.

Option B: unique constraint on active occupancy.

• Insert session row with (spot_id, status=OPEN) where a partial unique index enforces only one OPEN session per spot.
• If conflict, retry with another spot.

For this scale, Option A is easy to reason about.

Exit + payment flow

Goal: compute fee, charge once, release spot once.

1. Exit request arrives with session_id (ticket) or plate lookup (lost ticket flow).
2. Compute fee from entry_time → now (apply grace/rounding).
3. Create/confirm a Payment record using an idempotency key:
   • Key could be pay:{session_id}:{amount}:{pricing_version}.
4. If payment succeeds, transition session to PAID, then CLOSED.
5. Release spot (OCCUPIED → AVAILABLE) exactly once.

Important: don’t release the spot before confirming payment unless you explicitly allow “pay later” with an attendant override.

API design

Keep the surface small and state-driven.

• POST /v1/entry → allocate a spot, create session
• POST /v1/exit → compute fee, start payment (or return amount + payment token)
• POST /v1/payments/confirm → confirm payment for a session (idempotent)
• GET /v1/availability?floorId=&spotType= → counts + optional breakdown
• POST /v1/spots/{spotId}/override → attendant sets OUT_OF_SERVICE / forces AVAILABLE (audited)

API flow sketch:

Client/Gate → POST /entry
  → allocateSpot(txn) → createSession(OPEN) → return ticket

Client/Gate → POST /exit
  → computeFee → createPayment(idempotent) → confirm → closeSession → releaseSpot

Concurrency: the “two cars, one spot” problem

This is where seniors separate from templates.

What can go wrong

• Two entry lanes both see “Spot 12 is free” and both assign it.
• Gate controller times out and retries /entry, creating two sessions.
• Exit is processed twice (double release) or payment is confirmed twice (double charge).

Techniques that actually work

• Row-level locking on the chosen spot (transaction).
• Optimistic concurrency with a version field on Spot / Session.
• Idempotency keys on entry and payment confirmation:
  • entry:{gate_id}:{request_id}
  • pay:{session_id}:{amount}
• Uniqueness constraints:
  • One OPEN session per spot_id.
  • One OPEN session per vehicle_id.

A great answer says which combination you’ll use and why.

Failure handling (real world, not perfect world)

Devices offline or duplicated events

Treat gate/sensor events as at-least-once. Your backend must:

• Deduplicate by idempotency key.
• Allow reconciliation: if a sensor says “occupied” but DB says available, flag for attendant review.

“Lost ticket” / missing correlation

Make it explicit:

• If user lost the ticket, you can locate active session by plate.
• If you can’t prove entry time, charge a max-day rate and record a “manual override” reason.

Overrides (humans exist)

Add an audited override API:

• Spot OUT_OF_SERVICE.
• Force release with reason + actor identity.
• Create session manually.

The insight is that overrides are not “edge cases”; they are how systems survive reality.

Production angles

This section is where a senior engineer adds value beyond the basic model.

1) “Availability says 20 free, but drivers can’t find spots”

What it looks like: entry displays show availability, but the lot feels full; attendants get complaints; spot-by-spot reality disagrees with counts.

Why it happens: counts are cached/aggregated, sensors miss updates, or override workflows don’t emit correct state transitions. Your “available” definition is too naive (e.g., OUT_OF_SERVICE still counted).

What good teams do:

• Define availability as a function of spot state machine (AVAILABLE, OCCUPIED, RESERVED, OUT_OF_SERVICE).
• Rebuild counters periodically from truth (nightly or hourly reconciliation job).
• Alert on divergence: abs(derived_count - cached_count) > threshold.

2) Gate retries create duplicate sessions

What it looks like: one vehicle gets two tickets; billing disputes; occupancy appears inflated.

Why it happens: network timeouts cause client retries; backend is not idempotent on entry.

What good teams do:

• Require Idempotency-Key on /entry.
• Store a request log keyed by idempotency key → session_id.
• Make entry safe to retry and safe under partial failure (client didn’t receive response).

3) Double-charging on payment confirmation

What it looks like: user is charged twice; support burden is high; reconciliation is manual.

Why it happens: payment providers often recommend retrying confirmations; your system treats “confirm” as a new charge.

What good teams do:

• Create a PaymentIntent object and confirm it idempotently.
• Store provider reference id and enforce uniqueness.
• Release the spot only after the payment is in a terminal success state (or explicitly allow debt/override).

4) Clock skew breaks pricing

What it looks like: negative durations, weird fees around DST changes, disputes.

Why it happens: entry time taken from device clocks; timezone ambiguity.

What good teams do:

• Use server time (UTC) for all session timestamps.
• Treat device time as advisory metadata only.

How to use this in an interview

Pick one production angle and narrate it like a postmortem:

• Symptom: “counts diverge” or “duplicate tickets.”
• Root cause: “cached counters + missing idempotency.”
• Fix: “state machine + reconciliation + idempotency keys + constraints.”

That’s the difference between “I can draw a class diagram” and “I can ship systems.”