QnA/AMA 1 - How Airbnb (and Other Booking Platforms) Prevent Double Booking: Soft Blocking Explained
A Deep Dive into How Booking Systems Handle Multiple Users Competing for the Same Slot
After writing all Part 1, Part 2, Part3 One frequent question people asked on last Airbnb System Design series and that is true for all booking Systems "how does Airbnb take care of multiple user trying to get the same slot. How do they soft block it from the first user clicking on the dates or the seats"
Short Answer: Most booking platforms implement a temporary “hold” on the slot (dates, seats, tickets) in a fast in-memory store (e.g., Redis) with a time-to-live (TTL). When the first user selects the slot, the platform creates a short-lived reservation without immediately committing it to the main database. If the user completes payment within the time window (e.g., 5–15 minutes), the hold is confirmed into a real booking. If not, the hold expires automatically, freeing the slot for others.
Below is a more detailed explanation of common strategies:
1. Time-Limited “Soft Block” in a Fast Store
User Selects a Slot
When the user clicks on certain dates (or seats), the system checks if any existing soft block or booking is already in place.
If free, the system writes a temporary record to an in-memory store such as Redis. This entry typically includes:
The user ID or session ID.
The slot ID (dates, seat numbers, etc.).
A short TTL (e.g., 10 minutes).
During this TTL, the system treats the slot as “blocked” for that user.
TTL Expiration
If the user does not confirm and pay within the allotted time, the in-memory entry automatically expires.
The slot is then released and other users can book it.
Confirmation
Once the user decides to book and payment succeeds, the platform creates the final booking in the main database (e.g., “Booking” table).
At that point, the slot is fully reserved and no longer just “soft-blocked.”
Benefits
No Heavy DB Writes: The ephemeral hold is stored in Redis, avoiding constant writes to the main DB.
Efficient Locking: In-memory operations are very fast, so concurrency checks happen quickly.
Automatic Cleanup: The TTL ensures the hold is released even if the user’s app crashes, or they abandon the flow.
2. Distributed Locks or Lease-Based Approaches
Some platforms also use a distributed lock mechanism—again, often in Redis:
Acquire Lock
When a user selects the slot, the system tries to acquire a lock key in Redis for that slot.
If the lock is acquired, that user has exclusive access to finalize the booking for a short window.
Lock Timeout / Lease
The lock includes a timeout (lease) after which it auto-expires.
This prevents a scenario where a lock is never released if something goes wrong.
Release Lock
Upon successful payment, the system releases the lock and writes the final booking to the main DB.
If the user cancels or times out, the lock expires and the slot becomes available again.
This method is conceptually similar to the “soft block,” but uses a locking abstraction rather than a separate ephemeral data model.
3. Why Not Immediately Write to the Main DB?
Performance: If every “click” to check availability triggered a DB transaction, the system could experience high write contention—especially if many users are browsing.
User Abandonment: Many users select slots but never finish. Writing partial booking records clutters the DB and makes it harder to differentiate real bookings from unfinished ones.
Flexibility: By handling a short-term hold in memory, the system can easily roll back if the user fails to pay or changes their mind.
4. How to Handle Conflicts
Even with a soft block, race conditions can happen, e.g.:
Two users simultaneously click at nearly the same time.
One user’s network delay might cause the request to arrive slightly after another user’s hold.
Atomic check-and-set operations in Redis (or a locking approach) ensure only one hold can be placed at a time for the same slot. If a second user attempts to hold the same slot, they receive an error or fallback (e.g., “Slot unavailable”).
5. Implementation Outline
User Action
When the user selects dates/seats, call an endpoint:
POST /soft-block.
Soft Block Service
Check Redis for an existing block on that slot.
If none, create a key like
block:{slotId}with a value referencing the user and a TTL of 10 minutes.Return a success response or a “slot unavailable” message.
Payment Phase
Within the 10-minute window, user initiates payment.
On success, system calls
POST /confirm-booking, which reads the block from Redis, creates a definitive record in the main booking DB, then deletes the block or lets it expire.
Timeout Handling
If the user does not confirm, the key in Redis expires automatically after the TTL.
The slot is then free for other users.
Conclusion
Soft blocking (time-limited holding in memory) or distributed locking are the most common ways to handle a scenario where multiple users want the same slot—without immediately writing to the main booking DB. This pattern keeps the system responsive, prevents cluttering the DB with “half-baked” bookings, and ensures a fair process for users competing for the same resources.
