Requirements

Functional Requirements:

• Support multiple types of vehicles.
• Support configuration per lot
  • Different capacity for spot types per lot
  • Support different layouts
  • Support different opening hours
  • Support different rates
• Support UI for lot-managers
  • Adjust opening hours
  • Adjust rates
  • See free lot capacity

Non-Functional Requirements:

• Reasonable response times (<100ms P95) in 10 different countries.
• 2.3 requests / second avg, 12 requests / second peak <- relatively low traffic.
• Too much data for one DB. Shard geographically and add data backup in a separate region for recovery.
• 1 read (capacity / lot) before each write. Same number of reads as writes (roughly).
• Number of open spots is shown and requested very frequently. Add a cache for lot availability. Use cache for displays, check actual database upon entry.

Capacity Estimation

• 2.3 requests / second avg, 12 requests / second peak <- relatively low traffic.
• 500000 lots total.
• Each lot: 10 KB of data.
• 5000000 KB of Data -> 5 GB of data overall
• Pure replication would be sufficient, but interviewer said that sharding was required.

API Design

• GET /lots/{lot}/capacity -> returns capacity by type (json response)
• PUT /lots/{lot}/vehicles/{vehicle}/entry -> adjust capacity of lot for specific vehicle type(increment or decrement by one). Passed data includes vehicle PLATE ID. Entry time is set serverside. Called when the user enters the lot with a car.
• PUT /lots/{lot}/vehicles/{vehicle}/exit -> adjust capacity of lot for specific vehicle type(increment or decrement by one). Called when the user exits the lot with the car.
• GET /lots/{lot}/vehicles/{vehicle}/costs -> returns the parking cost for a specific vehicle. Called when the user wants to pay at the parking machine.

High-Level Design

• Frontend is Machine in the Parking lot. Potentially, user has an App, too.
• Backend uses cache for reading availability. All reads update the cache.
• Acutal entry checks database rather than cache to avoid that somebody goes into the parking lot if it's full.

Database Design

Detailed Component Design

The Loadbalancer is L7 and should distribute traffic to the correct microservices (assuming that design) based on the type of request. E.g. entry/exit microservice for movements in a parking lot.

The Postgres does not need sharding if we assume areasonable size of 10KB per parking lot entry because the total data volume would only consume 5GB.

We want multi-region databases and services to have short repsonse times, but a couple of regions all over the world will be sufficient because these operations don't have to be lightning fast. We can use Postgres Master databases with read replicas that also serve as failover instances. Read replicas should be in a different zone.