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:

• Latency must feel real-time to the user (<=200ms).
• The system must be horizontally scalable to handle traffic peaks without wasting resources during off-peak periods.
• It must be highly consistent to ensure that scheduled slots are genuinely available upon payment confirmation

API Design

//get reservations

GET /reservations/{id} -> 200 - {reservation-details}

//creates a reservation

POST /reservations/ -> 200 - {reservation-in-processing-details}

body -{

spot_id;

transaction_id;

check-in_date;

max-duration;

}

// check-in and check-out api to update the state of reservation once the car arrived and when it leaves

PUT /reservation/{id} -> 200 - {reservation-details}

High-Level Design

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.AWS API Gateway, which automatically scales to expose services to the world;

AWS Network Load Balancer (NLB) to distribute traffic among the requested service instances;

An ECS cluster with 3 separate applications to isolate the logic of each function, featuring auto-scaling policies that spin up new instances when CPU utilization reaches 55% and terminate them when it drops below 30%;

AWS MSK (Kafka) with userId as partition keyprovisioned with 3 topics—payment, appointment creation, and notification—to handle a high volume of transactions;

A reservation-creator service that deals new creations on database;

A payment adapter service that connects to an external payment API;

A notification adapter to send operation results back to the client;

A PostgreSQL database on AWS RDS with Multi-AZ replication enabled for scalability and high availability;

A Redis caching service to store data for the most frequently searched openings;".

Flow - Client makes a request to gateway, Once gateway receives request, user auth token is validated then api gateway calls service load balancer, then nlb routes the request to the most available service instance. Depends on the service called, the following happens:

• Reserve: Booking-request-service is invoke, then it creates a new pre-reserve event on pre-reserve topic; The return 200 to inform the client that the reservation is in process; reservation-creator consumes the event from pre-reserve topic and try to create a new reservation on db, if success, it will produce a payment event to payment topic and payment-adapter will consumes this requestPayment event and calls the payment service to conclude the purchasing. If payments occurs successfuly, payment-adpater creates a new events in cretion-topic, so reservation-creator can update reservation status on db. Everytime reservation-creator performs a update, it will invalidate the corelate register on redis.
• e, invalidate any date of reservation related to the spot on cache then creates a nofication event on notifier topic. The notifier-adtaper consumes the data from notifier topic in kafka the redirect the reservation request status, even success or failure, to the client.
• Check in or out: reservation-update-service is called to update reservation status on postgres, then the service invalidates the caching info relate to the spot, the return 200 to the client.

Detailed Component Design

MSK Cluster Architecture:

• Created with a multi-AZ multiplication factor and a replication factor of 6.
• Uses userId as the partition key to guarantee high availability.
• Ensures all operations from a specific user are processed in chronological order.

Producer & Broker Security:

• Multi-AZ region settings configured with a minimum replication factor of 2.
• System shielded by setting producer configurations to acks=all.
• Guarantees success responses only after messages are saved redundantly across all brokers.
• Idempotency settings enabled on the producer to prevent duplicate events.

Database & Transaction Integrity:

• Uses transaction_id as a database constraint.
• Ensures no duplicate transactions occur in the system.

Caching Strategy (Redis):

• Handled via Redis using an LRU (Least Recently Used) eviction policy and 1 min TTL policy configured, so stole items can be evict. Those evicted items will be rebuilt we a get request looks for this again on database;
• Keeps the most searched spots almost always available in the cache.
• Stores spot details along with a flag indicating availability or unavailability.
• Uses spot_id as the defined key for all cache items.

Once we are using ecs with auto-scale policy, going to create new application instances to attend to spikes, the load balancer is well positioned to routes all request, even tons of it, to instances. Once Kafka is suppose to supports tons of events with configs mentioned above, the consumer are no struggle to process the events in the right order. In order to makes this flow even better, we can add reservation-creator, payment-adapter and notifier adapter to the ecs cluster and configure auto-scaling working with application multthreads so events in the queue may be processed faster even at spikes.

To deal with reservation our architecture is designed to create a new reservation on db even when the payment is not proceed yet but with PENDING status. If payment is denied, reservation-creator will receive a event through pre-reserve topic so as to delete the pendeing reservation. We set a unique constraint on reservation table at db on period_id, spot_id and reservation_date to avoid duplacated reservation, but even so , if resevation-creator consumes a event trying to book a period that was already booked it will check in the db if there are any reservation for that period (this check will occurs in a single transaction with insert), it will receive a error a than will produce a notifier event informing the user that period reservation failed.

• To deal overlapping, the system will only book reservation in a period grouping of 30 minutes. User informs the entry time the max hours he intents to use the spot. A period cannot be reserved when it has a reservation into the previous 30 minutes or next ones. It mitigates physical location problems like shots delays and overstating.