Requirements

Functional Requirements:

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

Park request, pay, reserve

Non-Functional Requirements:

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

needs to scale with new parking lots adding this software

consistency over availabiblity, cant let reserve if its already full

Capacity Estimation

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

hundreds of cars parked at a time per lot, but only a few entering. read write ratio pretty similar, maybe a little more read. smaller scale system compared to other softwares

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/availability

• parameters: time and parking lot ID
• returns number of parking spots available at a certain time

POST/{user_id}/park

• parameters: user_id for unique car id, time entered lot, lot ID
• reservations use this as well
• returns success, writes to db this info

GET/price

• parameters: user_id, time exit
• read db for time enter, find total duration of stay and lot id and the price of this lot, calculate price
• return price

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.

user, load balancer (assign servers a certain number of parking lots each because theres only so busy each lot can be), rate limiter (can do very basic one because each lot cant receive that many calls at once, natural rate limiter at the gate), api gateway, cache (stores how busy each lot is, if certain lots are busier they'll be in the cache, add lots to cache when read request made on one not in cache, LFU cache type), database

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

SQL db

many relational tables

lot info table, index by lot id:

lot_id, price/hour, capacity

car info table, index by car id,

car/user id, time entered lot, lot id

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.

looking into server and how db is updated, whenever a car parks/enters lot, we update capacity, which is also returned when cars trying to reserve/updated then

rate limiting not much a problem due to the fact in real life a car can only enter a lot in around 15 seconds due to real life constraints