Design a Parking Garage

The ask

A car enters a garage, parks, and pays on exit. The system tracks which spots are free.

Drivers see a live free-spot count before they enter. Operators see occupancy and revenue for every garage.

The scope is many garages under one service. Each garage still works on its own when the network fails.

Exactness matters more than speed here. A spot sold twice angers two drivers at once.

Estimate the scale

One garage holds 1,000 spots. The service runs 10,000 garages.

1,000 spots x 10,000 garages = 10,000,000 spots in total.

Entries run at 5,000 a day per garage. That is a stated figure for one garage.

5,000 entries x 10,000 garages = 50,000,000 entries a day across the service.

50,000,000 entries / 86,400 seconds = 579 entries per second.

The write rate is modest. The read rate spikes when a big event ends and drivers check counts at once.

API and data

The entry operation takes a garage, a gate and a ticket or plate. It returns a parking session and a spot assignment.

The exit operation takes the session and a payment result. It closes the session and frees the spot.

The count operation takes a garage or a level. It returns free spots and full levels.

A parking session holds a garage, a spot, an entry time, an exit time and a state. The state moves from open to paid to closed.

A spot record holds a garage, a level, a spot number and a state. The state is free, reserved, occupied or blocked.

High-level design

Each garage runs a local controller at the gates. The controller talks to sensors in the spots.

An entry service owns sessions and spot state for one garage at a time. One garage has one writer for its spot state.

A payment service charges on exit. It never decides spot state.

A central service gathers counts from every garage. Drivers and operators read counts from there.

The central count is a summary. The garage record stays the source of truth for its own spots.

Deep dive: the last spot

Contention means many requests fight for the same small resource. Here the resource is one free spot.

Two gates can ask for the last spot in the same moment. A check followed by a separate write lets both pass.

The fix is one atomic step. The entry service marks the spot reserved and creates the session together, or it does neither.

A reservation expires if no car arrives within a short window. The spot returns to free without a person touching it.

Sensors confirm arrival. A reserved spot with no car and no sensor signal is a leak, and a background job releases it.

Deep dive: gates offline

A garage loses its network link during a busy hour. Cars still need to enter and leave.

The local controller keeps its own copy of spot state. Entry and exit continue on that copy alone.

Every local change is logged in order. The log carries a sequence number for each change.

The controller sends the log when the link returns. The central service applies the changes in order and rebuilds the counts.

Payment at an offline gate uses a stored card token or a pay-later record. The exit never waits on a distant payment service.

When sensors and records disagree

A sensor says a spot is empty. The record says a session is still open on it.

The record wins for billing, and the sensor wins for the free count only after a delay. A car may just be slow to settle.

Long disagreements go to an operator queue. The operator sees the session, the sensor history and the gate camera time.

A nightly job compares sessions, sensor states and payments. Mismatches shrink every day instead of growing in silence.

Evaluation and trade-offs

One writer per garage keeps spot state exact. It also caps one garage at one writer, and a single busy garage stays small enough for that.

Local control keeps gates moving during an outage. The price is a merge step when the link returns.

Exact spot state is the core promise. A parking garage system earns trust by never selling the same spot twice.

Counts can lag by a few seconds. Sessions and payments cannot lag at all.

Scale at a glance