Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

• system should be able to reserve parking lot space
• system should be able to process payments for parking lot space either at the gate or through a payment service

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

• strong consistency - so the user cannot double book a spot
• high availability - system should have little to no down time.
• low latency

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

GET /lots. This will return all the available lots to reserve.

PUT /lot/{lot_id}. This will update the state of the lot with the given vehicle number, parking duration, ticket id, flag determining whether the lot is reserved or not, and flag determining whether the lot is active. This returns a response with the associated ticket id. The body of this call contains all needed information

GET ticket/{ticket_id}. This will return the metadata of the ticket

PUT ticket/{ticket_id} with the body of whether the ticket is paid or not and remaining payment balance

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

The client's requests will first go through a load balancer (like ELB in aws) which will route the requests to an api gateway where the api paths will be authenticated and proceed onto the backend server. Once the request reaches the backend server, it will access the main database where it supports reads and writes. Since we need to support high availability, there is a shadow database where the main database propagates data updates to. The shadow database acts as a backup if the main database goes out of service for some reason. Once the data is retrived, it will be sent back to the server, then through to the client.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns..

The different entitites in this design are Lots and Tickets

Databases: SQL database. We want to use a SQL database because we have tightly coupled relationships between the three entities.

Lot Table - this table will have a primary key of lot id, and additional attributes such as:

• vehicle number
• parking duration
• ticket id
• flag determining whether the lot is reserved or not
• flag determining whether the lot is active or not

Ticket Table - this table will have a primary key of ticket id, and additional attributes are:

• lot id
• payment amount
• flag determining whether it's paid or not

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

If we were to focus on high availability, we could also have cross region disaster recovery, where if the main region goes out, there are backup regions that take over as the main region until the main region comes back on. Since we are using SQL based database, we can utilize something like the Amazon RDS across multiple availability zones to also ensure strong consistency. Since the lot id and the ticket ids are primary keys and we are never doing a full table scan in any point of our operation, we are guaranteed low latency.