Loading...
Parking fees, payment (including reserved booking)
Number of hours selection (and can add more later)
Vehicle size selection/Handicap Parking selection
Contact Support/AI Chatbot
Gate check-in/out
No-show handling
Admin panel to see transaction history and all parking lots an parking lot owner has
Accessible, Usability, Ease of Use
App for phones (android, apple)
Secure payment
Scalability (as more parking lot owners start using the app)
High-Availability (99.99%)
Strong Consistency
Violation Tickets
Web App
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
Each user does very little, somewhere between 0 and 4 times a day most likely. Let's say an average of 2. Parking lots can have hundreds of cars depending on its size, let's say an average of 200. Assuming it's fully booked, that's maybe 400 transactions a day per parking lot. If this would cover 10 nations with say 1000 parking lots in total, that's 400k transactions a day.
Database would be roughly equally write to read, since users would read their status about as much as they process it.
Storage: No BLOBs, only text. Transactions might, by GDPR, be required to not exist for too long in the database anyways (atleast not without user consent). Let's say we keep transaction history for a year. That's 400k*365 ~ 1.4b transactions, each can be assumed to be just a 100 bytes. That's 140b bytes, or about 140GB.
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...
REST-APIs
GET /lot/{id}?availability?from=...&to=...
GET /lot
POST /pay
PUT /lot/{id}
POST /ai_assistant
POST check_in
POST check_out
POST /reservation
for admins:
POST /login
POST /lot
GET /payment_history
WebSocket for chatting with support
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.
Frontend talks with Server. Server talks with Payment processor and Database.
To ensure HA, there can be multiple servers across multiple regions. To ensure consistency, there has to be one database with strong consistency.
400k transactions per day is about 1300 transactions per second. This might be enough to require caching and message queue. Caching only used for fast reads but not for reservations.
Load Balancer and API gate way that also does 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...
Lot
Transaction (lot_id as foreign key to lots, vehicle options, TTL)
Booking (lot_id as foreign key to lots)
AdminUser
Spot & Lot
Shard that shi
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
It's a small system so just the central server algorithm will be analyzed.
It will have the following:
Check-then-commit race
Hot-lot surge
Cache for speed, ensure no Stale cache. Cache TTL. Never cache bookings.
Ensure that two users cannot reserve the same spot via locking and db locking, return 409 conflict if there is one. "In a transaction, SELECT ... FOR UPDATE the spot row, re-check the window against existing reservations, then insert. First commits; the second re-reads, sees the overlap, returns 409."
Endpoints should be idempotent to make sure a retried call does the same reservation with no double bookings or double withdrawals. Use Idempotency-Key header, despite the fact that MDN discourages it.
OVerlapping intervals: Half-open [start, end) so old.end == new.start is allowed. Partial overlap -> reject.
Ensure correct error handling, idempotent retries and HA