The problem of double bookings and stale data is a common headache when launching online booking. The calendar shows incorrect slots, users waste time, businesses lose clients. We solve these tasks using row versioning and WebSocket invalidation. Over 40+ projects for clinics, salons, and services, we have accumulated a library of ready-made solutions: from optimistic locks to aggregated month loading with a single request. Below we break down key problems, their solutions, and the development process.
Problems We Solve
Race condition during booking. When two users simultaneously try to occupy the last slot. Without atomic updates, both get confirmation. We use row versioning and optimistic locking. Atomic operations in the database guarantee integrity.
Stale data on the client. The calendar shows occupied slots as free. Solution: streaming cache invalidation via WebSocket and reloading when returning to the page. In one project for a clinic network, we reduced month loading from 30 individual requests to one aggregated request, cutting rendering time by 70%.
N+1 queries when loading a month. Instead of 30 requests (one per day), we load aggregated data in one request per month, and time slots separately when a day is selected. This is a typical problem solved by proper caching strategy.
How to Avoid Double Bookings?
We use optimistic locking: each slot has a version field. When attempting a booking, we do an UPDATE with a version = ? check. If 0 rows are affected, the slot is already taken, and we return an error. For group slots, we check remaining > 0 and atomically decrement the counter. Optimistic locking allows processing 3 times more requests per second compared to pessimistic locking (SELECT FOR UPDATE). Collisions do not occur in 99.9% of cases.
What to Do with Caching Under High Load?
We apply a combination:
- Invalidation via WebSocket on changes.
- Stale-while-revalidate: show old data while updating.
- Increase
staleTimeto 5 minutes for less active days.
More on caching strategy
For optimization, we use stale-while-revalidate and WebSocket invalidation. Depending on load, TTL can be adapted.
In a project with 15 specialists and 300 slots per day, we set the month cache TTL to 60 seconds, reducing server load by 4 times without losing data freshness. Error caching (e.g., 500s) also helps avoid cascading failures.
Comparison of Slot Locking Approaches
| Approach | Reliability | Performance | Implementation Complexity |
|---|---|---|---|
| Optimistic locking | ★★★★☆ | ★★★★★ | ★★★☆☆ |
| Pessimistic lock (SELECT FOR UPDATE) | ★★★★★ | ★★☆☆☆ | ★★☆☆☆ |
| Confirmation queue (Redis + worker) | ★★★★☆ | ★★★★☆ | ★★★★★ |
Optimistic locking is the sweet spot: high speed in standard scenarios and acceptable collision protection.
Impact of Cache TTL on Response Time
| Cache TTL (sec) | Average Load Time (ms) | Server Load (RPS) | Data Freshness |
|---|---|---|---|
| 30 | 120 | 200 | High |
| 60 | 180 | 100 | Medium |
| 120 | 250 | 50 | Low |
For bookings, 60–120 seconds is optimal — a balance between speed and freshness.
Work Process
- Analytics: Gather requirements: number of resources, slot types, display rules (intervals, step, buffers).
- Design: Database schema, API (REST + WebSocket), React components.
- Implementation: Code, unit tests, integration tests for critical scenarios.
- Testing: Load testing (1000 concurrent bookings) and manual testing (different time zones, day boundary crossing).
- Deployment: To your server with documentation.
What's Included
- Source code of the calendar and API (Git repository).
- Documentation: API schema, deployment instructions, availability logic description.
- Access to a demo environment during development.
- Training for your engineers (1 session up to 2 hours).
- One month of technical support after deployment.
Timeline and Cost
Basic version of the calendar with API and component — from 4 to 6 working days. Cost is calculated individually depending on complexity: number of resources, slot types, need for external system synchronization. We have delivered 40+ booking projects. Get a consultation — contact us to estimate your project. Order your availability calendar development today.
Typical Mistakes We Avoid
- Ignoring time zones. We store everything in UTC, convert on the client.
- Too long cache TTL. For bookings, optimal is 60–120 seconds.
- Lack of visual state separation. A slot can be: available, booked, blocked, time-unavailable, full. Each has its own color.