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.)...
• Need to have low latency for both payment and gate checking cars in and out. You don't want to have people waiting too long
• Needs to be scalable for example if we are handling an event, if the system can't handle a huge influx of cars, customers will not be happy. We can achieve this by load balancing or vertical/horizontal scaling. "We need to handle traffic spikes of 10x normal load during events. We achieve this through horizontal scaling — adding more servers behind a load balancer — and auto scaling policies that spin up instances automatically when CPU or request rate exceeds a threshold.
• Needs to be available and reliable, if the system goes down-no cars can get in or out / payment can't be processed. If a failure does happen, we need to degrade gracefully. The system needs 99.99% availability for gate operations — that's less than 1 hour of downtime per year. A gate being down means cars physically cannot enter or exit which is a critical failure.
• Needs to be secured, we are dealing with payment methods and personal information
• Needs to be maintainable, once the system is up and running we need to be able to update as needed
• Needs to be consistent, two people can't book the same spot
• Needs to be data durable, payment records can't be lost and parking spot availability can always be recalculated if needed.

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

• POST /reservations to create a booking
• POST /checkin and /checkout for gate operations
• GET /spots/available to show what's open
• We use REST APIs here because these are straightforward CRUD operations. If we needed real time gate updates I might consider WebSockets but REST is sufficient for this use case

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 have the Request Path which is the Client, then the request gets fed to the API Gateway which handles Rate Limiting and Load Balancing. After that it gets sent to the services: Transaction, Reservation and Gate. On the Data Layer we have Transaction Service and Reservation Service connecting to both a Redis Cache and PostgreSQL DB. On the External and Ops layer, we have the Transaction Service connecting to the Payment Provider. The Gate Service connecting to the Lot Gate Devices. Reservation and Gate Services are connected to Background Jobs. All Three services are connected to a monitoring system like Datadog.

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.

• Reservation Service

S — State the problem

"I want to deep dive on the Reservation Service because preventing double bookings is the most critical problem in this system. If two people book the same spot simultaneously the business fails at its core function."

W — Why it's hard

"Under normal traffic this is straightforward. But during a high demand event like a concert or sports game, thousands of requests arrive simultaneously. A naive implementation reads a spot as available, then another request reads the same spot as available before either one commits — both proceed and we have a double booking."

I — Implement your solution

"I'd solve this with database transactions and pessimistic locking. When a reservation request comes in I open a transaction, lock that specific spot row, check availability, create the reservation, then commit atomically. If two requests arrive simultaneously one gets the lock and the other waits. When the first commits the second checks availability, finds the spot taken, and returns an error to the user.

An alternative is optimistic locking — add a version number to each spot row. Both requests proceed without locking but when committing check if the version changed since you read it. If yes someone else got there first — retry. This is faster under normal load but adds retry complexity."

F — Failure handling

"Two main failure scenarios. First — what if the service crashes after locking the spot but before confirming the reservation? I'd use a saga pattern — lock spot and create reservation are two separate steps each with compensating actions. If confirmation fails the saga releases the lock and marks the spot available again automatically.

Second — what if we get a flood of requests for the last available spot? I'd add a queue in front of the reservation service during peak load so requests are processed one at a time rather than hitting the database simultaneously. Dead letter queue handles any requests that fail after multiple retries."

For stale cache — I'd combine a short TTL of 30-60 seconds with Kafka driven cache invalidation on every booking. This minimizes the window where Redis returns outdated availability.

For hot lot surges I'd use a Redis sorted set queue to serialize requests

T — Tradeoffs

"The main tradeoff is pessimistic vs optimistic locking. Pessimistic locking guarantees no double bookings but creates contention under high load — thousands of requests queuing for the same lock degrades performance significantly. Optimistic locking is faster under normal conditions but requires retry logic and can cause poor user experience when many people are competing for the same spot simultaneously.

• • For a parking system I'd default to pessimistic locking because data consistency is more important than raw throughput — a double booking is a worse outcome than slightly slower response times. I'd switch to optimistic locking only if load testing showed locking contention was actually a bottleneck."
  • The main concern with pessimistic locking is hot lot surges — when thousands of requests compete for the same spot simultaneously. I'd mitigate this with a request queue and virtual waiting room for high demand events, similar to how Ticketmaster handles concert ticket sales.
  • The tradeoff with caching is consistency vs performance. I'd use write through caching with a 60 second TTL backup to maintain cache coherenc
• Transaction Service

S — State the problem

"I want to deep dive on the Transaction Service because payment reliability is the most critical and complex part of this system. If payments fail silently or customers get double charged the business loses trust immediately."

W — Why it's hard

"The challenge is that payments involve three separate systems — our Transaction Service, the payment provider like Stripe, and our database. Any one of them can fail at any point in the flow. The hardest scenario is when the payment succeeds at Stripe but our service crashes before we record it — now the customer was charged but has no reservation."

I — Implement your solution

"I'd handle this in two ways. First, idempotency keys — every payment request includes a unique client generated ID. If the same request is retried after a timeout, Stripe recognizes the key and returns the original result without charging again. This prevents double charging entirely.

Second, I'd use the saga pattern for the full reservation flow. Each step — lock spot, charge payment, confirm reservation — has a compensating action. If confirmation fails after payment succeeds, the saga automatically triggers a refund and releases the spot. No manual intervention needed."

F — Failure handling

"For the payment provider going down entirely I'd add a circuit breaker — after five consecutive failures we stop sending requests to Stripe and immediately return an error rather than making users wait for timeouts. I'd also publish a payment succeeded event to Kafka immediately after charging so even if our database write fails the event is persisted and a background consumer can retry the write."

T — Tradeoffs

• • "The main tradeoff is synchronous vs asynchronous payment processing. Synchronous means the user waits for payment confirmation before getting a response — simple and immediate but if Stripe is slow every request is slow. Async means we return pending immediately and notify the user when done — faster but more complex and the user doesn't get instant confirmation. For a parking system I'd choose synchronous because the user is standing at a gate and needs an immediate answer."