Design a scalable parking lot system

Read the full interview experience this question came from →

Quick Overview

Design a scalable parking lot system evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a scalable parking lot system

Company: Amazon

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design a parking lot system supporting multiple vehicle types and levels, entry/exit gates, ticketing, payments, availability tracking, and pricing rules (hourly, daily). Define core classes, relationships, and APIs for parking, un-parking, and querying availability. Address concurrency, data consistency, failures (e.g., lost tickets), and full-capacity scenarios.

Overview: Design a scalable parking lot system evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Read the full Amazon Software Engineer interview experience this question came from

|Home/Amazon/System Design
Amazon logo
Amazon
Jul 16, 2025
hardSoftware EngineerTechnical ScreenSystem Design
22
0

Design a scalable parking lot system

System Design: Multi-Level Parking Lot Service

Context

Design a production-grade parking lot system for a large, multi-level facility. The system should support multiple vehicle and spot types, multiple entry/exit gates, real-time availability, ticketing, payments, and pricing rules. Assume the system may operate across many lots and must remain available under concurrent use.

Requirements

  1. Functional
    • Support multiple vehicle types (e.g., motorcycle, car, truck/van, EV) and spot types (compact, large, handicapped, EV-charging).
    • Support multiple levels and multiple entry/exit gates per lot.
    • Entry flow: issue ticket (or identify by license plate), assign or admit to a spot/group, start a parking session.
    • Exit flow: compute charges based on pricing rules (hourly, daily), accept payment, end session, open gate.
    • Real-time availability tracking by lot/level/spot type.
    • Handle failure scenarios: lost tickets, payment failures, network issues, and full capacity.
  2. Non-functional
    • High availability and concurrency-safe spot allocation.
    • Data consistency for session state and payments; reasonable eventual consistency for availability counters.
    • Observability and auditability of financial transactions.
  3. Deliverables
    • Define core classes/entities and their relationships.
    • Define key APIs for parking, un-parking, payments, and querying availability.
    • Address concurrency control, data consistency, failure handling, and full-capacity behavior.
    • Low-level design variant: the round may instead ask you to implement the parking lot in code or detailed pseudocode in a shared editor, meaning the core classes plus park and exit operations that actually work, rather than a production design with services, APIs and payments.
      • In that variant, expect the interviewer to stop you mid-code with clarifying questions and what-if scenarios. Adjust the design as they come up instead of saving the changes for after the code is finished.
  4. Assumptions (make minimal, explicit choices if needed)
    • License plate recognition (LPR) is available but may be imperfect; tickets (QR/barcode) serve as fallback.
    • Option A: “Free parking” model where the driver selects a spot; Option B: “Assigned spot” model at entry. Design should support both; default to Option A for throughput, with optional assignment.
    • Pricing supports hourly and daily with configurable grace and rounding.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?
  • If your code protects spot claims with threads and locks, why is that synchronization needed? Walk through the check-then-act race when two gates try to claim the last free spot at the same moment, then explain how the design holds up when one service handles many gates and many lots.

Browse More Questions

More System Design•More Amazon•More Software Engineer•Amazon Software Engineer•Amazon System Design•Software Engineer System Design