Why parking lot is a classic LLD problem - Scalability Evidence

Scalability Analysis - Why parking lot is a classic LLD problem

Growth Table: Parking Lot System Scaling

Users / Vehicles	100 Vehicles	10,000 Vehicles	1,000,000 Vehicles	100,000,000 Vehicles
Parking Slots	Small lot, ~100 slots	Large lot, multiple floors	Multiple lots, city-wide	Nation-wide, multi-city
Entry/Exit Points	1-2 gates	10+ gates with sensors	Hundreds of gates, automated	Thousands of gates, distributed control
Real-time Tracking	Manual or simple sensors	Automated sensors, cameras	Integrated IoT devices, cloud	Distributed systems, edge computing
Data Storage	Local DB or file system	Centralized DB with caching	Distributed DB, sharding	Multi-region DB clusters
User Interaction	Simple app or kiosk	Mobile apps, web portals	High concurrency, APIs	Global scale, multi-tenant

First Bottleneck

The first bottleneck is the database that tracks parking slot availability and vehicle entries/exits. At small scale, a single database can handle updates and queries. As users grow, the number of concurrent updates and reads increases, causing delays and potential data inconsistency.

Scaling Solutions

• Database Scaling: Use read replicas to handle queries, write sharding to distribute updates by parking zones.
• Caching: Cache slot availability to reduce DB reads.
• Horizontal Scaling: Add more application servers behind load balancers to handle user requests.
• Partitioning: Divide parking lots into zones managed independently to reduce contention.
• Edge Computing: Use local controllers at gates to process data before sending to central servers.

Back-of-Envelope Cost Analysis

• Requests per second: For 10,000 vehicles with average 1 entry/exit per hour, ~3 requests/sec.
• Storage: Each vehicle record ~1 KB, 1M vehicles = ~1 GB storage.
• Bandwidth: Entry/exit data small (~100 bytes), 3 req/sec = ~300 bytes/sec, negligible network load.

Interview Tip

Start by explaining the core entities: vehicles, slots, gates. Discuss how real-time updates and concurrency affect design. Identify bottlenecks like database and network. Propose scaling solutions step-by-step, focusing on data partitioning and caching. Use simple analogies like managing parking zones as neighborhoods.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas to distribute query load and implement caching for frequent reads to reduce database pressure.

Key Result

The parking lot system first breaks at the database due to concurrent updates and reads; scaling requires partitioning data, caching, and horizontal scaling of application servers.