Design An Efficient Parking Lot System - System Design

System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

parking spots for various car types

accessibility spots closest to facility

each section has similar allocation of cars

bottom-up in case of floors

deallocate space for leaving car

assign parking space for incoming car

check how many spaces available

Non-Functional:

List non-functional requirements for the system...

scale to meet customer demand

available even if one server degrades

Capacity estimation

Estimate the scale of the system you are going to design...

2M cars

each car ~ 1 kb of data

system needs to register 2GB

API design

Define what APIs are expected from the system...

get-space

assign-space

reallocate-space

delete-space

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Car

id
parkingSpotId

Reservation

id
carId
parkingSpotId
duration
dateEntered
dateLeft

ParkingSpot

id
parkingSpotType

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

API Gateway - common interface for users to interact with the parking services

Load Balancer - scale the application as it grows (or shrinks)

Proxy - ensure encryption of transaction

Car Server - API service for registering vehicles

Reservation Service - creates and updates reservations

Parking Service - determines which parking spots are available based on vehicle and allocation

Relational Database - parking spaces, reservations, and vehicles

Cache - list of next available parking spots based on locality

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Reserve a Parking Spot

Gateway forwards request to the vehicle server, fronted by a load balancer
parking server looks up the car from the database to ensure it is valid, then passes the request to the reservation service
reservation service calls parking service to determine next available parking spot (if any)
parking service looks for available parking spaces in the database, marks it as reserved
service sets parking space as occupied in cache
reservation service creates reservation and returns confirmation to the user

user provides information to register a vehicle
car server receives request with car information
car service registers the car information in the database and updates the cache
if car is already registered, return an error

Update vehicle

same as register but allow updates to key fields

Terminate a reservation

parking service looks in cache for reservation, or to DB to fetch it
get the parking spot from the reservation and update the spot as available in the database
set the reservation end time in the database
returns complete confirmation to user

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

API will be a standard REST API that interfaces with the relational database. API Gateway will handle traffic routing to the appropriate service (vehicle, parking, reservation). Load balancers will map incoming requests to the available server. Geo-based round makes sense because of the need to minimize latency for end users. Within a region, round robin is a good strategy to prevent servers from getting overwhelmed due to thunder herds (big event). API will follow stateless practices as requests should not depend on state of server.

Database will be multi-master with replicas in several regions. As the application is write-heavy, having multiple nodes ensures high write throughput for peak reservation hours. Database will reside in a private VPC with security groups limiting write access to only the API services that need it.

For the API, locks must be acquired to create reservations - ensuring that conflicting requests do not overwrite each other.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Availability vs Latency

Service must always be available to accept reservations. Because reservations may come in from anywhere in the world (such as one traveling for a work or event), the origin of the request may be far from the location of the server where the reservation is held. It may take some time for the reservation to be replicated to other regions. There will be slight delay between reservation creation and observing the status of it - fine so long as users don't need to immediately know their reservation status.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Client makes reservations in rapid succession.

Server writes to the first reservation to the database but the second request doesn't see there is already a reservation in the system due to replication lag. It allows the second reservation to persist for the same car.

If a user immediate queries the system for the reservation after making it, it may come back as not found.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

Analyze the usage of the platform across geographies and time.

For hotspot regions, reroute read requests to the master node to ensure consistency of data. Can't do this for every region because it make overwhelm the writer nodes and degrade write throughput.