Loading...
Accomodate different types of vehciles
reservation
allocation
Entry, exit
Overstay fee
List the key non-functional requirements (performance, scalability, reliability, etc.)...
highly scalable
multiple tenants, and users
highly available
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
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...
System must support large amount of reads over writes as search is involved
Read Path
Reservation
User -> SearchService -> DB -> SearchService(return slots)
User (picks a spot) -> ReservationService -> DB (db level lock) -> ReservationService(books/rejects) -> Email/SMS notification
SearchService:
Searches a freespot for the vehicle type
Entry
User -> (click checkin or QR Scan) -> CheckInService (verifies QR or booking validity) -> DB (checking against db ) -> response via email/sms/inapp
Issues: what if the user overstays but another user in the queue for the same spot?
Exit
User -> Scans QR or Click checkout at the exit -> CheckOut Service (calculates amount) -> DB(returns the data for checkint) -> notification on due amount or send a comamnd to allow exit ( due calculation, payment and exit must be atomic)
Payment (for reservation/Exit)
User -> paymentservice -> PaymentChannel (Atomic transaction, payment, notification etc)
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.
We can use reservation service during checkIn or prebookng
ReservationService finds a spot, book it for a specific period , either before the booking or at the checkin
SearchService accepts vehicle type, time slots and searches for spots. We can either return one slot or many
CheckInService -> orchestrates checkin . if the user has a booking in place, it will check the scaanned data and confirms arrival. If there is no booking, it will call the reservation service which returns a booking and checks - in the vehicle
Checkoutservice -> It reads teh information and verifies if the scheduled duration exceeds the booked limit. if it does, then it calculates a price. these prices can vary. however, it would fall under OOD. Also, It would call the PaymentService and user can pay , return to checkout. in the end, checkout will let the user exit
PaymentService-> interface for multiple types of payments. It processes payment verifies, validates.
Datbase for tis design needs to be Non-RDBMS since they automaticlly favor shrading over RDBMS. They are highly scalable and faster in comparison to RDBMS when there are joins involved.
Locking happens at the row level using Rowversion. that is clean
Each service communicates with other services using gRPC. they must be hosted in a subnet to protect from external access. gRPC is faster compared to HTTP. While the user can rely on HTTP. Each service will have multiple APIs that acts as isolation between user and services
To protect fro sudden outbursts, i would use a leaky bucket approach rate limiting.
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...
Datbase for tis design needs to be Non-RDBMS since they automaticlly favor shrading over RDBMS. They are highly scalable and faster in comparison to RDBMS when there are joins involved.
Locking happens at the row level using Rowversion. that is clean
Each service communicates with other services using gRPC. they must be hosted in a subnet to protect from external access. gRPC is faster compared to HTTP. While the user can rely on HTTP. Each service will have multiple APIs that acts as isolation between user and services
To protect fro sudden outbursts, i would use a leaky bucket approach rate limiting.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Preventing doublebooking
using rowVersion. that way, we can prevent double booking
PaymentFailure
Each payment failure needs elaborate details like bank issue, account issues, server issues
Each failure needs to be documented, allow/freeze users from using certain vendors until the vendor system is properly working
DelayedExitwhen Another User in wait
This is tricky. allow some buffer in the parking lot so that users dont feel incovenient if another user delayes to exit
Notify Users on their exit time on a set period. 15 mins or 5 mins.
Another challenege would be having buffer spots that are underutilized would be disastrous. Look at the parking metrics, analyse overstays over a period. activate buffer zones during peak hours, certain periods etc
We need a data analytical service to read the trends