Booking hosting where two people cannot take one slot.
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.
Correct beats fast, then fast.
Every decision below starts from the fact that a stale calendar is worse than a slow one.
Availability is always live
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.
One slot, one booking
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.
Confirmation and payment together
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.
Calendars that stay quick as they fill
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.
Restore a day, not a season
Bookings are records people planned their lives around. Daily backups mean a bad bulk edit is recoverable rather than a round of apology emails.
The failures that cost a customer.
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.
- Availability read fresh on every request
- Reservation writes serialised
- Reminder emails sent on schedule
- Restore to before a bad edit
The slot check has to be instant.
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.
What we change for booking sites
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. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Will caching ever show a slot that is gone?
What stops a double booking?
Which booking plugins work?
Do reminder emails go out reliably?
Never sell the same slot twice.
Move the booking site across - migration is free, calendar included.