Design a Parking Lot Management System
Design a parking lot management system that handles vehicle entry/exit, tracks space availability through sensors with real-time display boards, processes payments, and manages violations including automated towing for unpaid parking.
Asked at:
c3.ai
Amazon
A parking lot management system is a real‑world platform that coordinates vehicle entry/exit, spot availability from sensors, real‑time display boards, payments, and enforcement for violations. Think of the parking experience at airports or malls: gates scan plates or tickets, boards show open spots by level, you pay via app or kiosk, and enforcement tows unpaid cars. Interviewers ask this to test if you can blend real‑time event ingestion (IoT sensors), strong consistency around scarce resources (parking spots), reliable multi‑step payments, and operational automation (violations/towing) into one cohesive system. The problem is intentionally small in surface area but touches critical system design skills: streaming vs request/response, contention and correctness, workflow orchestration, and graceful degradation at the edge.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to enter and exit the lot while the system validates access (e.g., ticket, license plate, permit) and logs the session.
Users should be able to see real-time availability on display boards and/or a mobile app, down to sections or levels.
Users should be able to start, manage, and pay for a parking session (prepay or postpay), and receive receipts or notifications.
Enforcement should be able to automatically detect unpaid or expired sessions and trigger violations (alerts, fines, towing) with auditability.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
Real-time availability drives driver experience and throughput at gates. Sensor updates can be bursty, noisy, and duplicated; display boards must stay responsive without thrashing. - Consider buffering sensor events with a durable log (e.g., a message bus) and fan-out to stream processors that update a fast in-memory store for display boards. This lets you smooth spikes and keep write paths decoupled from reads. - You could use idempotent processing with sequence numbers, heartbeats, and debouncing (time windows) to tame flapping sensors, ensuring your counters don’t oscillate wildly. - Push updates to boards via lightweight pub/sub and cache reads locally; if updates lag, fall back to last-known-good values and signal staleness.
Correctness under race conditions is where many designs fail. A wrong count leads to overselling spots, blockages, or empty boards showing 'Full'. - Keep a single source of truth per lot/section counter and use atomic operations (e.g., compare-and-swap) or transactions to increment/decrement. You could shard by lot/level to reduce contention. - Treat sensor input as signals, not truth: reconcile with gate events, plate scans, and periodic audits. Use dedupe keys and monotonic sequence numbers to avoid double-applies. - Enforce invariants: never allow counts below 0 or above capacity; route violations of invariants to a reconciliation workflow and alert operators.
Payments are multi-step and failure-prone. You need correctness (no double charge), user experience (low latency at exit), and operational recovery (retries/reconciliation). - Model payments as a state machine (initiated → authorized → captured/voided → refunded) and persist state transitions with an outbox pattern so you can safely retry without duplication. - Use idempotency keys end-to-end (client to provider) and store them with the session to handle retries due to network blips or timeouts. - Consider pre-authorization on entry and capture on exit for postpay, with asynchronous settlement and a fallback flow (e.g., grace period or manual kiosk) if the provider is down.
Enforcement affects customers and costs; a false tow is expensive and damages trust. You need a defensible, observable process. - Build a rules-based workflow that cross-checks multiple signals (no valid payment, plate recognition match, dwell time > grace period) before escalating from warning → ticket → tow. - Add human-in-the-loop checkpoints for irreversible actions: attendants confirm via handhelds with photos and location before dispatching a tow. - Keep an immutable audit log of events and decisions (who, when, why) to support dispute resolution and compliance.
Relevant Patterns
Relevant patterns that you should know for this question
Display boards and mobile views must reflect spot availability within seconds as sensors fire and cars move. A real-time updates pattern (event streams + pub/sub + fast caches) decouples ingestion from fan-out and keeps latency low under bursty loads.
Payments, exits, and violations are multi-step workflows with external dependencies and retries. Modeling them as sagas/state machines with durable steps ensures correctness across failures and supports compensations (void/refund, cancel tow).
Spot counters and the 'last few spots' scenario cause hot keys and concurrent updates. You need atomic increments, sharding, and idempotency to avoid overselling or negative inventory during peaks.
Relevant Technologies
Relevant technologies that could be used to solve this question
PostgreSQL is a solid system of record for sessions, payments, and enforcement with strong consistency and transactional guarantees. It pairs well with Redis (for speed) and Kafka (for eventing) and supports complex queries and auditing.
Similar Problems to Practice
Related problems to practice for this question
Both systems manage a scarce resource under high contention (seats vs parking spots) and must prevent overselling while handling real-time availability updates and payment flows.
Parking involves authorizations, captures, refunds, idempotency, and reconciliation with external providers—core challenges in designing a robust payment platform.
Real-time fan-out of rapidly changing data to many displays (boards, apps) with low latency mirrors the live comments problem’s need for streaming, caching, and pub/sub.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Treating raw sensor signals as the single source of truth for occupancy
Sensors can be noisy, duplicated, or out of order. Basing counters solely on them causes drift and flapping availability; you need reconciliation with gate events, debouncing, and idempotent processing.
Ignoring contention and invariants on spot counts
Without atomic updates and safeguards, concurrent entries/exits lead to overselling or negative inventory. This breaks user trust and can cause physical congestion at gates.
Tightly coupling display boards, payments, and towing to synchronous request paths
Blocking critical paths on external dependencies creates cascading failures and long tail latencies. Decouple with queues/streams, timeouts, retries, and graceful fallbacks to keep gates moving.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid September, 2025
Amazon
Mid-level
Early July, 2025
Amazon
Mid-level
Sensors sending updates on spots availability and display board showing availability in real time. Also towing system to tow cars parked without valid payment
Early April, 2025
Amazon
Mid-level
Your account is free and you can post anonymously if you choose.