High-Level Design

Each of the services, Login service, ParkingService, reserveService, and Gateservices will be in their respectivee containers. The loginservice will focus on user info / logins, reserveService will focus on the actual reservation of the Parking, and the ParkingService will focus on the availability of the parking spot., and the GateService will focus on the Gate openings. Note that the normal client's request on logging in / reserving a parking spot will go to the reserveService / LoginService, and the Gate hardware, it'll send request to the GateService bidirectionally. The ParkingService, which manages which parking spots are available, will communicate with the reserveService.

The database will store data like: User Information / Payment, Parking information, and the payment, as well as the Gate information. The Gate information.

Now let's go one by one.

When the user first reserves a parking lot, We'll call upon the reserveService. The reserveService will first reach out to the Cache. This Cache will be responsible for keeping the information for the parking spots that are currently taken. This is to ensure that there are no 2 same parking reservations that has the same parking_id. Since the user is making a reservation for the parking slot that is most likely not taken, and that reservation isn't in the cache, we would reach out to the Database for the parking information, and we would save this reservation onto the Cache itself. Now the cache should store those information until the expiration of the parking reservation + 1 hour, this 1 hour comes from how long user can have after their expired time to leave the gate. Similarly, the GateService will also utilize the Cache. When the customer is at the gate scanning a QR code to leave (most likely), the gateService will reach out to the Cache to retrieve the correct parking information. Once the parking session is verified, the gate will open, and the parking reservation will change its status to "expired". We will most likely keep the parking data for about a week, just in case something happens tot he parking instead of just deleting the reservation.

For the actual data that we are storing in the database, We would most likely shard the database based on the location of the parking spots. For example, we would have separate database for SF and LA parking lots. If we are utilizing distributed system, we would have this system on each of the kubernetes cluster for each region.

For the Payment system, I'm thinking of utilizing the third-party payment system like Stripe. It's a tradeoff between technical overhead on creating our own payment system, and the cost of using the 3rd party system.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10