Practice/Amazon/Design a Parking Lot Management System

Design a Parking Lot Management System

System DesignMust

Problem Statement

Design a parking lot management system that handles vehicle entry and exit, tracks space availability throughout a multi-level facility, supports advance reservations, processes payments based on duration, and provides real-time occupancy dashboards for operators. The system must handle peak traffic during events and rush hours, prevent double-booking of reserved spaces, and maintain accurate availability even when sensors fail or network connectivity is intermittent.

At Amazon, interviewers ask this to evaluate your ability to manage contended physical inventory with real-time state tracking, handle IoT device integration with intermittent connectivity, design reservation and payment workflows, and build geo-spatial search for multi-facility scenarios. The challenge combines online systems (reservation, payment) with edge computing (sensor processing, gate control) under strict reliability requirements.

Key Requirements

Functional

• Real-time availability -- display current occupancy and available spaces per level, zone, and spot type (compact, standard, EV charging, handicap)
• Vehicle entry and exit -- automatically detect vehicles at entry/exit points, assign spaces, open gates, and track occupancy changes
• Advance reservation -- users reserve a space for a time window via mobile app, with the system preventing double-booking and holding the space until arrival
• Dynamic pricing and payment -- calculate charges based on duration, spot type, time of day, and event pricing; process payments on exit

Non-Functional

• Scalability -- support 500+ parking facilities with up to 2000 spaces each, handling 100,000+ reservation requests per hour during events
• Reliability -- maintain 99.9% uptime for entry/exit gates; support offline gate operation for up to 30 minutes during network outages
• Latency -- return availability queries within 300ms; open gates within 2 seconds of vehicle detection
• Consistency -- strong consistency for reservations to prevent double-booking; eventual consistency acceptable for search results and analytics

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Space Inventory and Reservation Atomicity

Parking spaces are finite, contended resources. During events, many drivers compete for the same facility simultaneously. Interviewers want to see atomic inventory management.

Hints to consider:

• Use conditional writes to atomically claim a specific space: UPDATE space SET status='reserved' WHERE id=X AND status='available'
• For general availability (no specific space preference), use atomic counter decrements per (facility, zone, spot_type)
• Reserve spaces with TTLs: if the driver doesn't arrive within 30 minutes, the reservation expires and inventory is released
• Implement idempotency using (user_id, facility_id, time_window) as deduplication keys to handle checkout retries

2. Sensor Integration and Real-Time Occupancy

Entry/exit sensors, individual spot sensors, and cameras generate continuous events that must be processed to maintain accurate occupancy. Interviewers probe how you handle unreliable sensors.

Hints to consider:

• Process entry/exit events through a streaming pipeline to update occupancy counts in real-time
• Deduplicate sensor events (multiple triggers for a single vehicle) using vehicle detection IDs and short deduplication windows
• Reconcile individual spot sensors with entry/exit counts to detect and correct drift
• Handle sensor failures by maintaining health scores and falling back to entry/exit count-based occupancy when spot sensors are offline

3. Offline Gate Operation

Gates must continue operating even when the central system is unreachable. Interviewers look for edge computing strategies.

Hints to consider:

• Deploy a local controller at each facility that caches active reservations, pricing rules, and recent transactions
• The local controller validates reservations and opens gates independently during network outages
• Buffer transactions locally and sync to the central system when connectivity restores, with conflict resolution favoring physical events
• Use cryptographically signed tokens for reservation validation that the local controller can verify without server contact

4. Payment and Pricing Flexibility

Parking charges depend on duration, spot type, time of day, and events. Interviewers want to see accurate, auditable payment processing.

Hints to consider:

• Store pricing rules in a configuration service with versioning so disputes can reference the rules in effect at entry time
• Pre-authorize payment on entry and settle the final amount on exit based on actual duration
• Handle edge cases: early departure (refund), overstay (additional charges), and payment failure (grace period with barrier)
• Make payment processing idempotent with deduplication keys to prevent double charges on retries

Suggested Approach

Step 1: Clarify Requirements

Confirm scope. Ask about the number of facilities and spaces per facility, whether the system manages individual spot tracking or only aggregate counts, and which spot types exist. Clarify reservation policies (advance booking window, cancellation policy, no-show handling). Determine if multi-facility search and comparison is in scope. Ask about sensor types available and connectivity assumptions.