Design a scalable parking lot system

Last updated: Mar 29, 2026

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.

|Home/System Design/Amazon

Design a scalable parking lot system

Amazon

Jul 16, 2025, 12:00 AM

hardSoftware EngineerTechnical ScreenSystem Design

11

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

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.
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.
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.
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.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

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?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

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

Your design canvas — auto-saved