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:

List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...

API Design

API that reserves a reservation

• Takes customer information such as name, car, model, color, check-in/check-out time
• returns validated reservation

API that processes payment for the reservation

• Credit card information
• Returns parking spot

Specifically, these 2 APIs can be combined and be an atomic operation ensuring data consistency

• Once the API begins a reservation, a parking spot will be automatically generated and 'locked'
• All of this data can be returned as json format and encrypted with AES-256
• We can tokenize the payment information and any PII
• If the API fails, we cancel the transaction and no data is saved

API that scans a barcode to enter and leave, validating the parking

• Each barcode must be unique
• Covers early exit as you just scan the code to leave

These are all our post methods

For our get methods

API that gets the reservation if users want to check their times, spot, and location

All of our APIs have error logging that are consolidated in a table within our

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.

We can start at the client level

• Our UI will contain input validation to cover SQL injections and cross site scripting
• We can connect to our AWS EC2 instance
• By using AWS, we can implement load balancing requesting more instances when traffic is at its peak such as during the day or on the weekends
• Also, by using AWS, we can cover our EC2 instances across regions ensuring durability and availability
• Using Elastic File service, we can easily scale our services
• After our API is called through AWS Lambda and ran through the EC2 instance, we can use Redis cache for helping read times and storing data
• We can store our api data in our RDS like MySQL

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Step 3: Start with the Reservation & Payment Service

• How it works: Receives customer info, validates, reserves a parking spot, processes payment, writes data to DB.
• Scaling: Horizontally via EC2 auto-scaling, stateless APIs. Use queues (SQS) if payment processing can be async.
• Trade-offs: Atomic operations required (reservation + payment). Slightly higher complexity to maintain consistency.
• Data structures: DB tables with indexes on parking spot ID, timestamps, customer ID. Possibly a hash map in Redis to check available spots quickly.

Step 4: Parking Lookup / Barcode Check Service

• How it works: User scans barcode, system validates the barcode, checks if reservation exists, allows entry/exit.
• Scaling: Many concurrent reads → use caching (Redis) to reduce DB hits. Can deploy multiple EC2 instances behind a load balancer.
• Trade-offs: Need low latency. Cache invalidation must be handled carefully if a user cancels a reservation or leaves early.
• Data structures: Redis hash for barcode → reservation mapping. Possibly a queue for logging entries/exits.

Step 5: Caching Layer (Redis / ElastiCache)

• How it works: Stores frequently accessed data like current reservations, available spots, barcode mappings.
• Scaling: Horizontal clustering (shards), LRU eviction for memory efficiency.
• Trade-offs: Eventual consistency. Risk of cache misses; must always fall back to DB. Cost vs speed balance.
• Algorithms: LRU for eviction. Hash maps for fast lookups. Pub/sub if you need to notify EC2 instances of cache updates.