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 YouTubeStatement 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 automationBooking Plane
Access + Async Plane
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
endPros
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 nothingAlternative: 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.
