Availability is the one thing on a booking site that must never come from a cache, and reserving is the one write where being a second out of date costs you a customer.
Every decision below starts from the fact that a stale calendar is worse than a slow one.
Calendar and slot queries bypass the page cache entirely. A visitor sees what is free right now, not what was free when somebody else loaded the page a minute ago.
The moment of reservation is a locked write, so two people pressing confirm at the same second cannot both succeed. The second one is told immediately rather than discovering it by email.
A booking that takes payment is two systems agreeing. Worker capacity is sized so the confirmation write and the payment callback both land instead of one timing out.
Availability queries scan a date range against every existing booking, and that range grows all year. Those lookups are indexed so December is as fast as January.
Bookings are records people planned their lives around. Daily backups mean a bad bulk edit is recoverable rather than a round of apology emails.
Booking sites do not lose money by loading slowly. They lose it by showing a slot that is gone, or taking two reservations for one table.
A visitor picks a date, waits, picks a time, waits. Those two waits are the whole booking experience, and neither of them can be served from a cache.
Availability is a read that cannot be cached and reservation is a write that cannot race. Everything else follows from those two.
| Setting | What we do | Why |
|---|---|---|
| Availability endpoints | Excluded from the page cache entirely | A cached calendar offers a slot that somebody else already took, and the customer only finds out after paying. |
| Reservation writes | Serialised so concurrent confirms cannot both win | Two people confirming the same slot in the same second is not rare on a popular date, and the database must decide rather than the application hoping. |
| Date-range queries | Indexed across the bookings table | Checking availability compares a range against every existing booking, and that table only grows through the year. |
| Reminder scheduling | Platform-driven rather than visitor-driven | A reminder that fires late because nobody visited overnight is a missed appointment. |
| Payment callbacks | Given worker headroom outside the front-end pool | The confirmation and the provider's callback arrive together, and dropping either leaves a booking in an ambiguous state. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the booking site across — migration is free, calendar included.