Practice/C3 AI/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 through IoT sensors with real-time display boards, processes payments, and manages violations including automated towing for unpaid parking. The system serves large facilities like airport garages and shopping mall parking structures with thousands of spaces spread across multiple levels and sections.

Consider the operational complexity: sensors on each spot report occupancy changes, entry and exit gates must validate access quickly to avoid queuing, display boards at each level show available spots in real-time, and the payment subsystem supports prepay via mobile app, pay-on-exit at kiosks, and permit-based access. Enforcement must detect vehicles that overstay or park without valid payment and trigger escalating actions from alerts to fines to towing, all with a clear audit trail.

Key Requirements

Functional

Vehicle entry and exit -- the system validates access at gates via ticket, license plate scan, or permit, logs the session start and end times, and opens the barrier within 2 seconds of validation
Real-time availability display -- display boards at each level and section, as well as a mobile app, show current open-spot counts updated within seconds of occupancy changes
Payment processing -- users pay for parking sessions through prepay on a mobile app, pay-at-kiosk on exit, or monthly permits, with receipts and notifications sent automatically
Violation detection and enforcement -- the system identifies vehicles with expired sessions or no valid payment, issues alerts and fines, and triggers towing requests with full auditability

Non-Functional

Scalability -- support facilities with 10,000+ spots and sensor update rates of hundreds of events per second, with the architecture extensible to a network of lots
Reliability -- gates must continue operating during partial outages; sensor pipeline must tolerate transient failures without corrupting occupancy counts
Latency -- gate validation and barrier opening under 2 seconds, display board updates within 5 seconds of a sensor event, payment confirmation under 3 seconds
Consistency -- strong consistency for payment records and violation state; eventual consistency acceptable for display board counts with reconciliation

What Interviewers Focus On

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

1. Sensor Event Ingestion and Occupancy Accuracy

Parking sensors fire frequently, can produce duplicate or out-of-order events, and occasionally malfunction. Basing spot counts solely on raw sensor signals leads to drift and flapping availability numbers.

Hints to consider:

Ingest sensor events through a durable message stream like Kafka, partitioned by lot section, to handle bursts and enable replay for debugging
Apply deduplication and idempotent processing using sensor ID and timestamp to filter duplicate or stale events
Reconcile sensor-derived counts periodically with gate entry/exit logs as a secondary signal to catch drift
Implement debouncing so that rapid on-off-on sensor toggles (e.g., a car adjusting its position) do not cause flapping counts

2. Contention on Spot Counts and the Last-Spot Problem

When a section has only a few remaining spots, concurrent entry events can race to decrement the same counter, potentially driving it negative or overselling the section.

Hints to consider:

Use atomic increment and decrement operations (e.g., Redis INCR/DECR or Postgres advisory locks) to serialize updates to section-level counters
Shard counters by section and level so that contention is localized to hot zones rather than a single global counter
Design idempotent counter updates keyed on event ID so retries do not double-count
Accept slight over-reporting of availability on display boards (eventual consistency) while maintaining strong consistency at the gate for actual entry decisions

3. Payment Workflow and Multi-Step Orchestration

A parking payment touches session lookup, rate calculation, payment gateway authorization, receipt generation, and gate release. Each step can fail independently, and the system must handle partial failures without leaving sessions in inconsistent states.

Hints to consider:

Model the payment flow as a state machine or saga with explicit states: session active, payment initiated, payment authorized, receipt sent, gate released
Use idempotency keys on payment gateway calls so that retries after timeouts do not result in double charges
Implement compensating actions: if payment authorization succeeds but receipt generation fails, the session should still be marked paid and the receipt retried asynchronously
Store all state transitions in an append-only audit log for compliance and dispute resolution

4. Violation Detection and Enforcement Pipeline

Enforcement must identify unpaid or overstayed vehicles, escalate through alerts and fines, and coordinate towing -- all without false positives that would damage customer trust.

Hints to consider:

Run a periodic job that compares active sessions against payment records and time limits, flagging violations with configurable grace periods
Use a state machine for each violation: detected, alert sent, fine issued, tow requested, tow completed, with timestamps at each transition
Integrate license plate recognition at entry and exit to correlate vehicles with sessions, reducing reliance on tickets alone
Provide an override mechanism for operators to dismiss false positives and record the reason for audit purposes

5. Edge Resilience and Graceful Degradation

Parking lots are edge environments where network connectivity to central services can be intermittent. Gates must keep traffic flowing even during backend outages.

Hints to consider:

Deploy a local gateway controller at each facility that caches recent permits, active sessions, and spot counts, allowing entry and exit to proceed offline
Queue events locally during connectivity loss and replay them to the central system when connectivity is restored, using idempotent processing to avoid duplicates
Display boards should fall back to showing "spaces available" without precise counts if the sensor pipeline is degraded
Design the architecture so that the worst-case degradation is slightly stale data, not blocked gates or lost revenue

Practice/C3 AI/Design a Parking Lot Management System

Design a Parking Lot Management System

System DesignMust

Problem Statement

Key Requirements

Functional

Vehicle entry and exit -- the system validates access at gates via ticket, license plate scan, or permit, logs the session start and end times, and opens the barrier within 2 seconds of validation
Real-time availability display -- display boards at each level and section, as well as a mobile app, show current open-spot counts updated within seconds of occupancy changes
Payment processing -- users pay for parking sessions through prepay on a mobile app, pay-at-kiosk on exit, or monthly permits, with receipts and notifications sent automatically
Violation detection and enforcement -- the system identifies vehicles with expired sessions or no valid payment, issues alerts and fines, and triggers towing requests with full auditability

Non-Functional

Scalability -- support facilities with 10,000+ spots and sensor update rates of hundreds of events per second, with the architecture extensible to a network of lots
Reliability -- gates must continue operating during partial outages; sensor pipeline must tolerate transient failures without corrupting occupancy counts
Latency -- gate validation and barrier opening under 2 seconds, display board updates within 5 seconds of a sensor event, payment confirmation under 3 seconds
Consistency -- strong consistency for payment records and violation state; eventual consistency acceptable for display board counts with reconciliation

What Interviewers Focus On

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

1. Sensor Event Ingestion and Occupancy Accuracy

Hints to consider:

Ingest sensor events through a durable message stream like Kafka, partitioned by lot section, to handle bursts and enable replay for debugging
Apply deduplication and idempotent processing using sensor ID and timestamp to filter duplicate or stale events
Reconcile sensor-derived counts periodically with gate entry/exit logs as a secondary signal to catch drift
Implement debouncing so that rapid on-off-on sensor toggles (e.g., a car adjusting its position) do not cause flapping counts

2. Contention on Spot Counts and the Last-Spot Problem

When a section has only a few remaining spots, concurrent entry events can race to decrement the same counter, potentially driving it negative or overselling the section.

Hints to consider:

Use atomic increment and decrement operations (e.g., Redis INCR/DECR or Postgres advisory locks) to serialize updates to section-level counters
Shard counters by section and level so that contention is localized to hot zones rather than a single global counter
Design idempotent counter updates keyed on event ID so retries do not double-count
Accept slight over-reporting of availability on display boards (eventual consistency) while maintaining strong consistency at the gate for actual entry decisions

3. Payment Workflow and Multi-Step Orchestration

Hints to consider:

Model the payment flow as a state machine or saga with explicit states: session active, payment initiated, payment authorized, receipt sent, gate released
Use idempotency keys on payment gateway calls so that retries after timeouts do not result in double charges
Implement compensating actions: if payment authorization succeeds but receipt generation fails, the session should still be marked paid and the receipt retried asynchronously
Store all state transitions in an append-only audit log for compliance and dispute resolution

4. Violation Detection and Enforcement Pipeline

Enforcement must identify unpaid or overstayed vehicles, escalate through alerts and fines, and coordinate towing -- all without false positives that would damage customer trust.

Hints to consider:

Run a periodic job that compares active sessions against payment records and time limits, flagging violations with configurable grace periods
Use a state machine for each violation: detected, alert sent, fine issued, tow requested, tow completed, with timestamps at each transition
Integrate license plate recognition at entry and exit to correlate vehicles with sessions, reducing reliance on tickets alone
Provide an override mechanism for operators to dismiss false positives and record the reason for audit purposes

5. Edge Resilience and Graceful Degradation

Parking lots are edge environments where network connectivity to central services can be intermittent. Gates must keep traffic flowing even during backend outages.

Hints to consider:

Deploy a local gateway controller at each facility that caches recent permits, active sessions, and spot counts, allowing entry and exit to proceed offline
Queue events locally during connectivity loss and replay them to the central system when connectivity is restored, using idempotent processing to avoid duplicates
Display boards should fall back to showing "spaces available" without precise counts if the sensor pipeline is degraded
Design the architecture so that the worst-case degradation is slightly stale data, not blocked gates or lost revenue