Most booking software is hosted in one region. Customer in Singapore booking from a US-hosted platform is making round-trip requests across the Pacific — every click, every load, every confirmation.
That round-trip adds up. The implications:
The latency cost
Round-trip times by geography (typical):
- US-East to US customer: 30-80ms
- US-East to UK customer: 90-150ms
- US-East to India customer: 250-300ms
- US-East to Australia customer: 200-250ms
- US-East to South America: 150-200ms
A booking flow that makes 10 sequential requests:
- US customer: 0.3-0.8s of latency
- India customer: 2.5-3s of latency
The Indian customer’s booking page feels sluggish, not because the backend is slow but because the network is the bottleneck.
What edge deployment changes
Edge-deployed booking software runs in 200+ data centres globally. The customer’s request hits the nearest data centre — typically under 50ms away — instead of the single origin.
Cloudflare Workers and similar edge platforms run code in:
- North America: 30+ cities
- Europe: 40+ cities
- Asia-Pacific: 30+ cities
- Africa: 8+ cities
- South America: 10+ cities
For a customer in Mumbai, the booking flow runs from the Mumbai data centre. For a customer in São Paulo, it runs from São Paulo. Same code, regional execution.
Why it matters for conversion
Booking-page conversion drops with latency:
- Page load > 2 seconds: ~25% bounce rate
- Page load > 5 seconds: ~50% bounce rate
A 2-second flow on US infrastructure becomes a 4-second flow for international customers. Conversion drops proportionally.
For service businesses with international customer bases (hotels, travel-related, online lessons, e-commerce-adjacent), the conversion gap is real.
Database, too
The compute layer at the edge isn’t enough by itself — the database also has to be regionally available.
Traditional setup: app server at the edge, database in US-East. The edge server still has to round-trip to the DB.
Modern edge databases: Cloudflare D1, FaunaDB, PlanetScale with replicas, Neon with read replicas. Read queries hit the nearest replica; writes still go to the primary.
For booking-page reads (showing availability), reading from the regional replica is fine. For writes (creating a booking), the write hits the primary — but writes are rarer than reads.
Per-tenant data isolation at the edge
Cloudflare D1 is a per-tenant database (one D1 per business). This combines two trends:
- Edge deployment for performance
- Multi-tenant data isolation for security
Each business’s data is in its own isolated D1 database, served from the regional edge. There’s no “shared customer table” across tenants — a row-level security bug can’t leak data because there are no shared rows.
What this means for booking software in 2026
The platforms that will dominate the next decade:
- Run code at the edge (Cloudflare Workers, Vercel Edge, Deno Deploy)
- Store data in edge-aware databases (D1, Turso, Cloudflare KV, FaunaDB, PlanetScale)
- Issue per-tenant database isolation
- Route customer-facing emails / SMS through customer- controlled providers
Legacy booking platforms (Acuity, Mindbody, Booksy) run on traditional cloud infrastructure (AWS/GCP, single region). They’re mature but architecturally a generation behind.
How Zedule does it
Zedule runs entirely on Cloudflare:
- Workers for compute (200+ data centres)
- D1 for per-tenant databases
- KV for fast tenant routing
- Pages for the marketing + dashboard apps
- R2 for asset storage
Every booking request from a customer hits the nearest Cloudflare data centre. The pool worker (handling all booking-page traffic) is regional. The customer’s data is in a regional D1.
This is what allows the $100/year price point — the infrastructure cost per tenant is dramatically lower than running per-tenant containers on AWS.
Trade-offs
Edge deployment isn’t perfect:
- Cold starts are still a thing (less so on Workers vs Lambda, but real)
- Long-running tasks don’t fit the edge model
- Some database operations require primary-region round-trips
- Debugging is harder with code running globally
For booking workloads (short-lived requests, mostly reads), the trade-offs favour the edge.
What to ask when evaluating booking software
- “Where does your platform run?”
- “Where is customer data stored?”
- “What’s the typical page-load time for customers in [your region]?”
If the platform can’t answer, they’re likely on single-region infrastructure.