2024·Solo backend engineer

Mgari

Car rental booking engine

FastAPIPostgreSQLRedisGoogle Maps API

//0x01—problem

Two customers booking the same vehicle for overlapping dates at the same moment is the one failure a rental platform cannot tolerate — and availability needs to reflect where a car actually is.

//0x02—architecture

//0x03—technical challenges

→Concurrent booking requests for the same vehicle and date range must not both succeed
→Availability needs to account for a vehicle's current location, not just its calendar
→Public booking endpoints need protection from abusive request volume
→Booking logic needed to stay correct under load without introducing a queue-based architecture

//0x04—solutions

Row-level locking for reservations

Booking writes use SELECT FOR UPDATE on the vehicle's availability row inside a transaction, so two concurrent requests for overlapping dates serialize correctly — the second always sees the first's reservation.

Geo-fenced availability

Vehicle locations are checked against requested pickup areas using the Google Maps API, so a car isn't shown as available to a customer it can't realistically reach.

Sliding-window rate limiting

Public endpoints are rate-limited using Redis INCR with EXPIRE-based sliding windows, keeping booking and search endpoints stable under bursty traffic.

//0x05—results

Zero double-bookings under concurrent reservation testing
Location-aware availability using Google Maps geo-fencing
Redis-backed sliding-window rate limiting on public endpoints