14 - Design a Parking Service

📋 Jump to Takeaways

🎁 A parking sensor flips from "occupied" to "free." Within one second, every driver within a mile sees an updated count. How do you build that with 50,000 sensors reporting at once?

A parking service manages parking lots, tracking spot availability in real-time, letting users find nearby parking, and handling entry/exit with automatic billing. This combines IoT events (sensors), geospatial queries ("parking near me"), and real-time counters. A different flavor from the pure-software systems we've designed so far.

Parking Service Requirements

Parking Service Functional Requirements

Search for available parking near a location
View real-time spot availability per lot
Entry/exit detection (sensor or camera at gate)
Automatic billing based on duration
Optional: reserve a spot in advance

Parking Service Non-Functional Requirements

Metric	Target
Lots managed	50,000 (mix of small street lots and large garages)
Total spots	10 million
Availability updates	Real-time (within 2 seconds of car entering/exiting)
Search latency	< 200ms for "parking near me"
Uptime	99.9% (~8.7 hrs/year, ~43 min/month, ~86 sec/day)

Parking Service Scope Exclusions

Navigation/routing to the lot (use Google Maps API)
EV charging station management
Monthly pass and subscription billing

Parking Service Estimation

Entry/exit events: 10M spots × 3 turnovers/day = 30M events/day → ~350/sec
Search queries: 100K peak concurrent × 1 query/30sec = ~3,300/sec
Availability data: 50K lots × 4 spot types × 8 bytes = negligible

Low throughput. The challenge is real-time accuracy and geospatial search, not scale.

Parking Service High-Level Design

┌─────────────────────────────────────────────────────────────────┐
│                      PARKING SERVICE                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────┐     ┌──────────────┐     ┌──────────────────┐     │
│  │  Mobile  │────►│  API Server  │────►│  Geospatial DB   │     │
│  │  App     │◄────│              │◄────│  (PostGIS/Redis) │     │
│  └──────────┘     └──────────────┘     │  find nearby lots│     │
│                                        └──────────────────┘     │
│                                                                 │
│  ┌──────────────┐  ┌──────────────┐    ┌──────────────────┐     │
│  │  IoT Sensors │─►│  Occupancy   │───►│  Availability    │     │
│  │  / Cameras   │  │  Service     │    │  Cache (Redis)   │     │
│  │  (entry/exit)│  │              │    │  lot → count     │     │
│  └──────────────┘  └──────┬───────┘    └──────────────────┘     │
│                           │                                     │
│                           ▼                                     │
│                    ┌──────────────┐                             │
│                    │  Billing     │                             │
│                    │  Service     │                             │
│                    │  (duration   │                             │
│                    │   × rate)    │                             │
│                    └──────────────┘                             │
└─────────────────────────────────────────────────────────────────┘

Parking Service Deep Dive

Real-Time Availability with Redis Counters

Each lot has an atomic counter per spot type:

DECR lot:123:available:regular   ← car enters
INCR lot:123:available:regular   ← car exits

Why Redis? Atomic, sub-millisecond, handles concurrent entry/exit without locks. If DECR returns negative → lot is full, INCR back and reject.

Geospatial Search

GEOSEARCH lots FROMLONLAT -73.98 40.75 BYRADIUS 1 km ASC

Returns lots within 1 km, sorted by distance. Filter by availability (only lots with free spots). Rank by distance + price + availability percentage.

Entry/Exit Flow

Car enters → sensor detects → Occupancy Service:
  1. DECR available count
  2. Create session (lot, plate, entry_time)

Car exits → sensor detects → Occupancy Service:
  1. INCR available count
  2. Close session (set exit_time)
  3. Billing: calculate charge (duration × rate)
  4. Charge card on file

Dynamic Pricing

Adjust rates based on occupancy:

0-50% full:   base rate ($3/hr)
50-80% full:  1.5× ($4.50/hr)
80-95% full:  2× ($6/hr)
95-100% full: 3× ($9/hr)

Update every 5 minutes. Displayed in search results so users can compare before driving there.

Parking Reservations

For pre-booking (airport parking):

DECR counter (hold the spot)
Store reservation with start_time
If user doesn't arrive within 30 min → INCR back (release) + charge no-show fee

Key Takeaways

Redis atomic counters for real-time availability

INCR/DECR handles concurrent entry/exit without locks. The counter IS the availability. No scanning, no counting rows.
Geospatial indexing enables location-based search

PostGIS or Redis GEO finds lots within radius efficiently. Combine with availability filtering for useful results.
IoT events drive the system, sensors are the source of truth

The system reacts to physical events (car enters/exits). Sensor reliability is critical. Add camera backup and local buffering for network outages.
Dynamic pricing balances supply and demand

Higher prices when lots are full incentivizes users to park elsewhere. Simple threshold-based rules work well.

Want the full design? The example "Parking Service at Scale" covers spot-level tracking with bitmaps, reservation overbooking strategies, sensor fault tolerance, and billing edge cases.

🎁 This next problem isn't about distributed systems at all. It's about state machines, scheduling algorithms, and object-oriented design. Can you model an elevator?