System Design Space
Knowledge graphSettings

Updated: March 2, 2026 at 9:38 AM

Smart parking system

mid

Public interview at C++ Russia 2023: distributed locking and protection against double booking.

Public System Design interview at C++ Russia 2023, where the interviewer is Alexander Polomodov invites candidate Pavel to design smart parking system — a classic problem for distributed systems with high consistency requirements and handling concurrent data access.

Source

Original analysis

This analysis is based on a publication in the “Book Cube” Telegram channel.

Перейти на сайт

Video recording of the interview

The full recording of the public interview (30 minutes) is available on YouTube.

Watch on YouTube

Statement of the problem

Smart Parking System

Management system for a network of paid parking lots with access control through barriers. The user reserves a seat in advance through the application and receives a guarantee of its availability and uses automatic entry/exit based on license plate number.

Functional Requirements

Search for parking

GPS search with display of available places

Booking

Atomic decrement of the free space counter

Cancel due to timeout

Automatic cancellation after 15 minutes of no-show

Entry/exit

Automatic license plate recognition via access control system

Non-functional requirements

High Concurrency

Peak loads in the morning/evening, especially in shopping centers. Many users compete for the same places.

No Overbooking

Double booking is absolutely prohibited. Strict data consistency is required.

Related case

Hotspot systems

Patterns for handling hotspots in geo-sharded systems.

Читать обзор

High-Level Architecture

Smart Parking: High-Level Map

reservation + access control + timeout automation

Booking Plane

Driver App
search + reserve
API Gateway
auth + routing
Booking Service
reserve/cancel
Inventory Lock
Redis semaphore
Booking DB
state + history

Access + Async Plane

ANPR/LPR -> Entry Service -> Gate Controller
plate check + barrier command
Event Bus -> Delay Queue -> Timeout Worker
TTL expiration pipeline
Notification
push/email

Smart parking overview: online reservation, entry/exit control, and automatic spot release by TTL.

The architecture divides three independent circuits: online booking, physical access And timeout automation. This allows you to scale the API, LPR loop, and background workers in isolation.

Core Entities

Parking

{
  id: UUID,
  gps_coordinates: {lat, lon},
  total_capacity: int,
  free_spots_counter: int, // semaphore!
  address: string
}

Booking

{
  id: UUID,
  user_id: UUID,
  parking_id: UUID,
  car_plate: string,
  created_at: timestamp,
  expires_at: timestamp,
  status: enum (pending, confirmed, cancelled, expired)
}

Interviewer feedback

The candidate initially forgot the essence Booking, focusing on operational tables. However, order storage is critical for analytics, auditing, and state recovery.

Atomic semaphore counter

The central technical challenge is to provide atomicity of decrement counter when booking. We need a compare-and-swap operation with a check: the counter should not fall below zero.

Redis: Lua script

Recommended
-- parking_book.lua
local counter = redis.call('GET', KEYS[1])
if tonumber(counter) > 0 then
  return redis.call('DECR', KEYS[1])
else
  return -1 -- No free seats
end

Pros

Single-threaded, atomicity, >100k ops/sec

Cons

Requires Redis Cluster for HA

PostgreSQL: UPDATE with F-expression

UPDATE parkings 
SET free_spots = free_spots - 1
WHERE id = $1 AND free_spots > 0;

-- affected_rows = 0 → no places available

Pros

Full ACID guarantee, CHECK constraints

Cons

Row-level locks with high competition

Recommended approach

Redis for temporary blocking (fast, TTL) + PostgreSQL for final recording (ACID). Redis as the "first line of defense", the database as the source of truth.

Delayed Message Queues

If the user has reserved a place, but does not arrive for 15 minutes, the system should automatically release space and cancel the reservation.

AWS SQS Delay Queues

# When booking
sqs.send_message(
    QueueUrl=timeout_queue,
    MessageBody={"booking_id": "...", "parking_id": "..."},
    DelaySeconds=900 # 15 minutes
)

# After 15 minutes the worker checks:
# - If the car does not arrive → INCR counter, cancel the reservation
# - If you arrived → do nothing

Alternative: RabbitMQ Delayed Message Plugin for self-hosted solutions.

Geo-Sharding

Parking lots are naturally tied to geography, creating an ideal opportunity for location-based sharding.

Strategy

  • Shard key based on geo-hash (msc_ for Moscow, spb_ for St. Petersburg)
  • "Find nearby" requests are served from one shard
  • Minimizing cross-shard operations

Hotspots: Popular locations (the center of Moscow) are divided into sub-zones + read replicas.

Key Findings

Atomic semaphore

The central problem is the race condition when decrementing the counter. Redis + Lua or PostgreSQL with WHERE free_spots > 0.

Event Sourcing for Audit

Append-only event log (booking_created, car_arrived, car_departed) for full auditability.

Delayed Queues for TTL

SQS/RabbitMQ with a 15 minute delay to automatically cancel unused reservations.

Geo-partitioning

Geolocation sharding minimizes cross-shard operations and ensures data locality.

Interviewer Rating

✓Strengths

  • Correct definition of scope
  • Quick bottleneck detection
  • Completeness of scenarios (success, failure, timeout)
  • Accounting for geo-distribution and NFR

⚠ Areas for improvement

  • Booking entity forgotten
  • Specific RPS and sizing not discussed
  • The final choice of database is not reasoned
  • ~60% of the volume covered in 30 minutes

Final score: Hire with condition. Senior position requires more depth in technology selection and numerical assessments.

Related materials

Related chapters

Enable tracking in Settings

System Design Space

© 2026 Alexander Polomodov