Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
system should give number of available parkings at any time
system should allocate parking to every arriving vehicle
system should save priority parking for necessary individuals (disabled / family/ trucks)
payment for reservation
no show allocated to someone else / reservation open
List the key non-functional requirements (performance, scalability, reliability, etc.)...
Application should be highly available sitting behind load balancers and multi instanced incase of failover
Application should be secure only authorised individuals should be allocated a parking
Application should use a reliable algorithm to allocate the best parking based on the various constraints
Application should have low latency
serialisation in allocation
gate checks to drive billing
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
The scale of the application is dependent on the number of parking spaces available and the turnover rate of each parking spot
Assuming the parking lot has 100 spots and each visitor is parked for an average of 30 minutes the application will need to be able to handle 5 request per minute.
The application will need a large amount of CPU as it is computation heavy each instance should have 20GB memory
The application will have a read write ratio of 1:1
the database will need to have 50 bytes per row and grow to 10 GB in a year with 120MB perday
Daily average users will be 2400
fleet scale accross multiple physical locations
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...
login - post request
reserve - post request (book a slot)
getAvailable - get request (view current bookings)
pay - post request (complete payment)
checkin - postRequest (enter parking lot)
checkOut - post request (exit parking lot)
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.
system has an entry layer frontend application where clients interact
backend has controllers and dto's
each instance has a database connection which is used to read reservation information and write reservation information
on arrival each physical allocation of a parking spot is atomocally and uniquely allocated to client this unique id is stored in the db to avoid overlapping of allocated spots
secure payments endpoint connecting to relevant payment systems
backend application sitting behind load balancers/ api gateway which maintains the number of instances incase of failover
webhook callback from payment system to transition the reservation state
cache of avaliability
gate device hardware
monitoring job to report arrivals / departures
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...
have tables:
users - user_id, username, encrypted password
users oath - client_token, user_id fk
reservations - reservation_id, date_created, reservation_date, vehicle_type, status, user_id
parking_spots - parking_id, location, reservation_id, status
normalisation through users and user_oath tables
index on reservations table reservation_id with a unique contraint
partioning done on the reservation id as this table has the most entries
distinguish parking lot table( id, capacity, contact_info)
spot_id stored on reservation not other way round
trancaction table with entry / exit times
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
reservation booking scenario
user logs into application
user requests to see available slots for certain dates
parking information is cached in the application
check cache first if not found check in database and write to cache
user selects desired parking date and quantity
reservation is tentatively created
user is directed to payment service provider
async call made to payment provider
reservation is updated once callback is received
check in scenario
reservation booking system and check in systems can be seperated / run on different instances
user arrives recieve notification call from monitoring gate hardware machine service
current available parking spots pulled from cache as the parking table is high traffic on this application
have periodic cache invalidation strategy
user is allocaed parking spot with a unique and atomic id created, this id is of the type structured id which cannot be scanned in the db
db updated
is application falls over check in request can be sent again / started from the mid point without any affect on the parking spot
unique constraint on spot_id and reservation or insert where not exists / loser write fails
check happen in same transaction/ authorotative write, availablity validated at authorotative commit
hold ttl unreserved holds free up