Requirements

Functional Requirements:

• Allow reservation of a parking spot.
• Process payment for the reservation.
• Enable parking of a car in the reserved spot.
• Support early departure before reservation time expires.
• Gate check-in/out.
• Handle no show.

Non-Functional Requirements:

• CAP Theorem: Consistency over availability: Parking system would want to update the user as and when a particular spot is taken, hence avoiding 2 users from booking the same spot.

Also, users would want immediate updates about the slots that were booked or not, and not till they reach the payment section.

• Strong Consistency: Strong consistency using RDBMS, distributed transactions and pessimistic locking should be implemented
• Availability: Users can expect minimal downtime since consistency is prioritised.
• Scalability: The system should be highly scalable, supporting 1M DAU.
• Security: Vehicle data should be encrypted before storing, as this might reveal user details when linked with the vehicle name from registration.
• Reliability: System should be reliable, by ensuring that the data is not lost and the spot is effective when booked.
• Durability: Data in DB should be highly durable and should not be lost due to hardware failures. Data upto 2 years should be stored in cloud, in case of audits/ formal enqueries

API Design

1. GET api/v1/parking/slots/available?floor={floor}
2. POST api/v1/parking/slots/booking payload: { slot: string, floor: number, vehicleID: string, priority: number, vehicleType: VehicleType(enum), check_in: time}
3. POST api/v1/parking/slots/confirm: {slot, vehicleId, vehicleType}
4. PATCH api/v1/parking/gate/checkout payload: {slot: string, floor: number, vehicleID: string, checkout: timestamp(Date)}
5. DELETE api/v1/parking/slot?slot={slot}&vehicleId={vehicleId}

High-Level Design

1. User sends api requests which gets smartly routed to respective microservices in the API Server by api gateway, and the requests are distributed internally by the load balancer
2. API Server microservices store the immediate data(last 1month data) in RDS / Aurora. For audit purposes, 2 years data is then migrated to S3 Glacier using serverless components like AWS Lambda and S3 Lifecycle policies.
3. API Server also uses Redis for caching slots, in order to decrease the number of requests to the DB for reads.

Detailed Component Design

1. User: Android/ Website
2. WAF: Web Application Firewall , required to filter malicions IPs and bots, part of security
3. CDN: Content Delivery Network to deliver assets with minimal latency at edge locations. This can be used for rendering available slots at edge locations
4. API Gateway: Smart routing of requests based on API route path. Handles Authentication, Authorization, Rate Limiting using token bucket algorithm with 60 tokens per sec per user.
5. Load Balancer: Application Load Balancer for traffic distribution to Parking Lot Service. Round robin algo used for equal distribution of traffic, preventing sticky sessions and celebrity problem.
6. Parking Lot Service: The Core of the system. Handles Fetching available slots by floor, vehicle Type, Booking of slots, confirming booking upon successful payment, and auto removal of booking if user didnot show up. Uses transactions to upsert data into DB, Caches frequently accessed data in redis for faster lookup and reduce read requests to DB.
7. Cache: Redis used as a distributed Cache to store slot available as well as the current status of each slots. All the data is written in an Append only file for backups. If one redis node fails, another can read this file and keep it sync with the previous failed node.
8. Database: RDBMS based DB such Postgres is used due to its strong consistency, and relational based data storage.

1. RDS Proxy: A proxy server can be used for maintaing connection pool in cases of extreme load
2. Kafka: Event driven Message Broker that Parking service publishes notification events which the notification consumes to send notification to the user
3. Notification Service: Integrated with twilio for sending sms to the respective user

Working of Payment Service:

1. For booking an appointment, a post request is sent by the user on selecting a slot and the respective slot is marked as reserved by setting the isReserved booking as true
2. Once the user clicks on submit a confirm POST request is sent to the server, where the PArking slot service calls the payment initiate t. If the payment isccess, then a transaction begins to update the slot record to isBooking: true, a new vehicle entry is added, and an audit is entered in the audit table. In case of any failure ( such as payment failure;/ network issue/ or upsert failure in db), the entire transaction is rolled back, hence atomic.
3. POST commit in db, a kafka event blished in the nfication topic, for the notification service to consume and send a notification to the respective user via twilio.
4. The slots updated are cached in redis, so that reads are fetched through cache consistently, thus reducing db load.
5. On every DB write, the cache will be updated, thus going for a write-through policy, preventing stale data in cache.
6. Since the row is locked in the distributed transaction, the data in the respective rows will be recent data, and not stale data.
7. In the event of popular slot, priority of the user will be considered for reserving the row.
8. For this, Priority queue can be used to fetch the highest priority user and assign the slot same.

Cache:

1. Stores the slots data ( sync with DB)
2. Write through Policy followed
3. Cache eviction strategy: Least Recently Used ( LRU) with TTL of 5min
4. Distributed Redis Cluster with AOF for backups in case of redis node failures and crashes

Furthur enhancements:

1. A User with higher priority can be given preference by over writing the sae slot record and sending a notification to both the users, and updating the slot for the previous user with a new slot
2. to decouple the services, SQS can be used, for higher scalability.
3. Kafka brokers can have replication factor of 3, thereby having 2 replica and 1 master, with 4 partitions for each topic.
4. user data and vehicle data can be encrypted and stored in RDS/Aurora using KMS
5. Aurora DB can be used for higher availability and better performance. DB and service pods can be deployed in multi AZ and multi Region for high reliability.
6. service pods can be part of auto scaling group which the load balancer can access their elastic ips. The scaling can be controlled by queue length metric