Conflicting bookings—two clients grabbing the same slot—and last-minute cancellations without notice are common headaches for service businesses. We build mobile booking apps that solve these issues at the architecture level. With extensive experience, we have delivered over 30 projects for beauty salons, medical centers, and fitness clubs—from cross-platform solutions to native apps with Full HD animations and real-time WebSocket. Each app undergoes strict review against App Store Review Guidelines and Google Play Console policy to ensure smooth store releases.
Avoiding Race Conditions in Booking
Race condition is a classic headache. Two clients see a free slot at 2:00 PM with the same staff member and tap "Book." Without proper synchronization, both get confirmations. We use optimistic locking: a slot record with a version field in the database or SELECT FOR UPDATE on the server. The mobile client handles 409 Conflict and shows "Sorry, the slot was just taken. Please choose another time" with an updated list of available windows. This reduces no-shows by 20% and saves client budgets through deposits and push reminders.
Why Real-Time Schedule Updates Are Critical
If a staff member works across multiple channels (website, Instagram, third-party services), slots can diverge. A WebSocket connection to the server is the best approach: when the schedule changes on any channel, all clients instantly see the new picture. Compared to periodic polling, WebSocket delivers updates 10 times faster and saves bandwidth. We use web_socket_channel on Flutter and react-native-websocket on React Native.
Organizing the Schedule in the Booking App
The mobile schedule interface features horizontal date scrolling plus a vertical list of slots. On iOS we use UICollectionViewCompositionalLayout, on Android—RecyclerView with nested RecyclerView. On Flutter—TableCalendar or a custom solution with drag-and-drop support for staff.
Slots are calculated considering: staff working hours, service duration, already booked slots, and gaps between appointments (e.g., 15 minutes for preparation). All logic runs on the server; the client receives precomputed data. For multi-staff scenarios (client picks a service, system assigns the first available), we use round-robin or priority by rating.
Push Reminders and Cancellation from Notification
Reminders 24 hours and 2 hours before are scheduled jobs on the server (Sidekiq/Celery). The client doesn't control timings; only receives pushes. On iOS we use UNNotificationAction for cancellation directly from the notification. On Android—action buttons in FCM. Users can cancel without opening the app—convenience that reduces support load.
Payment: Three Scenarios and Holds
- No prepayment—basic booking.
- Partial prepayment (deposit)—20% of the amount, held against no-show. Refunded if canceled X hours before.
- Full online payment—amount captured immediately.
Advanced option—hold: PaymentIntent with capture_method: manual (Stripe). Money is "frozen" on the card at booking time, captured after service, refund via refund. Requires confirmPaymentIntent confirmation.
| Scenario | Description | Use Case |
|---|---|---|
| No prepayment | Booking without financial commitment | Trial visits |
| Deposit | Hold part of the amount, refund on cancellation | Salons, medical centers |
| Full payment | Pay entire service at booking | Fitness classes, consultations |
What's Included in the Work
- Business process analysis and architecture design (C4 models).
- Backend development (REST/GraphQL API) and mobile client.
- Payment gateway integration (Stripe, Tinkoff, YooKassa) and push services (FCM/APNs).
- WebSocket setup for real-time scheduling.
- Testing: unit, integration, load (simulating 1000 concurrent bookings).
- Deployment to App Store / Google Play with store compliance.
- Developer documentation and end-user instructions.
- 1 month post-launch support.
| Stage | Timeline (estimate) |
|---|---|
| Analytics & prototype | 1 week |
| MVP development | 4–6 weeks |
| Full-scale platform | 2–3 months |
| Testing & deployment | 1–2 weeks |
How We Test Booking from Unit Tests to Load Testing
- Unit tests—cover core logic (slot calculation, staff prioritization).
- Integration tests—simulate two clients booking simultaneously, verify locks.
- Load testing—1000 concurrent requests via Gatling or k6, ensure 99% of requests are processed in <200ms.
- UI tests (Detox/XCUITest)—walk through key scenarios (book, cancel, pay).
Common early mistakes:
- No gap between slots—clients complain about overlaps.
- Sync only via polling—delays up to 30 seconds, lost bookings.
- Ignoring staff timezone—clients from other time zones book wrong slots.
We guarantee stable app performance under high load—verified on 30+ production projects. Investment for MVP is discussed individually; timelines start from 4 weeks. Contact us for a consultation and get a preliminary roadmap. Request a demo tailored to your project.
Race condition—a classic parallel access problem we solve with optimistic locking.