Design a multi-level parking 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 multi-level parking system that tracks floors, parking spots, and vehicle types. Some vehicles may occupy multiple adjacent spots. Define core data models and APIs to handle vehicle entry and exit, spot allocation and release, and queries such as available spots by type and by floor.
Quick Answer: Design a multi-level parking 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 the backend for a multi‑level parking facility. The system must track floors, rows, parking spots, and vehicle types. Some vehicles require multiple adjacent spots. The service should allocate and release spots on vehicle entry/exit and support queries for availability by vehicle/spot type and by floor.
Assume:
Vehicles: motorcycle, car, van/SUV, bus/truck (some may require k adjacent standard spots).
Spots: motorcycle, compact, regular, large, EV (flag for charging capability), each on a specific floor and row, with a sequential index for adjacency.
Adjacency means contiguous indexes within the same row.
Requirements
Define core data models (entities, relationships, key fields).
Define APIs for:
Vehicle entry (allocate spot(s) and issue a ticket/allocation).
Vehicle exit (release spot(s)).
Queries: available spots by type and by floor; availability for a given vehicle type.
Address allocation for vehicles that need multiple adjacent spots.
Note key constraints, concurrency handling, and performance considerations.
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?