Development of a Booking Platform for Services

Imagine two clients hitting "Book" on the same time slot simultaneously. That race condition is the root cause of double bookings and lost orders. We build booking platforms that eliminate this problem from day one. With over 5 years of experience ranging from solo practitioners to marketplaces with thousands of providers, we know how to schedule, take payments, and sync calendars reliably.

The Problem: Double Booking and Lost Orders

A typical scenario: a beauty salon uses Excel to manage appointments. Clients call, double bookings happen, and orders get lost. We build automated systems that handle scheduling, online payments, and calendar sync. The most common technical challenge is the race condition: when two clients try to book the same slot at the same time. Without proper locking, both succeed, leading to conflict.

How Our Schedule Model Prevents Conflicts

The provider's schedule defines available booking slots. The foundation is two tables: schedules for regular hours and schedule_exceptions for exceptions (vacations, urgent matters). The free slot generation algorithm: take working hours from schedules → subtract already booked slots from bookings → subtract buffer time between appointments → return free intervals.

-- Regular working schedule
CREATE TABLE schedules (
  provider_id, day_of_week INT (0-6),
  start_time TIME, end_time TIME
);

-- Exceptions (weekends, vacation)
CREATE TABLE schedule_exceptions (
  provider_id, exception_date DATE,
  is_available BOOLEAN, -- false = unavailable
  custom_start TIME, custom_end TIME -- alternative schedule for that day
);

-- Booked slots
CREATE TABLE bookings (
  id, provider_id, client_id, service_id,
  start_at TIMESTAMPTZ, end_at TIMESTAMPTZ,
  status ENUM('pending', 'confirmed', 'cancelled', 'completed')
);

Eliminating Double Booking with PostgreSQL Advisory Locks

Double booking is the classic problem in booking systems. Our approach uses PostgreSQL advisory locks (see PostgreSQL documentation) to serialize concurrent bookings for the same slot.

SELECT pg_advisory_xact_lock(provider_id, unix_timestamp_of_slot);
-- check availability
-- create booking
-- lock is released automatically at transaction end

An alternative is a unique index on (provider_id, start_at) with INSERT ON CONFLICT DO NOTHING. However, we prefer advisory locks because they don't require uniqueness for all booking states (e.g., cancelled bookings should not block slots). Advisory locks are also faster under high load (over 100 bookings per second).

Managing Provider Services and Buffers

Each provider configures their services: name, description, duration, price, buffer time after session, and client requirements. Buffer time is critical: if a session lasts one hour, a 15-minute buffer means the next slot starts only after 1:15. This prevents lateness and gives time for preparation.

Cancellation Policies

Standard cancellation policies are compared below:

The provider chooses one policy. On client-initiated cancellation, the refund is calculated automatically via Stripe Refund. On provider-initiated cancellation, the client gets a full refund.

Google Calendar Integration Step by Step

1. OAuth2 Authorization: The provider authorizes access to their calendar via standard OAuth2 flow.
2. Event Synchronization: New bookings automatically create events in Google Calendar via Google Calendar API. Events block slots on the platform.
3. Backward Sync: Blocking events from the provider's calendar (e.g., personal meetings) mark them as unavailable.
4. Change Handling: On cancellation, the corresponding event is deleted or marked as confirmed.

Automated Reminders and Notifications

Automated reminders reduce no-shows. We set up:

• Booking confirmation (immediate)
• Reminder 24 hours before (email + SMS via Twilio)
• Reminder 1 hour before (push notification in mobile app)
• Feedback request 2 hours after visit

Comparison of Double Booking Prevention Methods

The choice depends on load. For high-traffic platforms (100+ requests/s), we recommend advisory locks.

What's Included in Our Work

When you order a booking platform development, we provide:

• Architectural diagram and API documentation
• Source code in a Git repository
• Database migrations for all environments
• Payment gateway integration (Stripe, YooKassa)
• Google Calendar / Outlook integration
• Notification setup (email, SMS, push)
• Deployment and operations guide
• Administrator and provider training
• 3-month warranty support after launch

Why Choose Us

We have developed over 30 booking systems for various industries—from beauty salons to venue rentals. Our experience guarantees no double booking, reliable payment processing, and scalability to thousands of concurrent requests. Certified PostgreSQL and React engineers. The average reduction in admin time after implementation is 40%, saving up to 150,000 rubles per year. Platform commission is 15%.

Timelines

MVP (provider profile, schedule, booking, payment, notifications): 2 to 3 months. Full-featured marketplace with analytics, mobile app, and multiple providers: 4 to 6 months. Contact us for a project assessment—we'll find the optimal solution and timeline. Order a consultation to discuss details.

How to Avoid Discrepancies in Commission Calculations

Commission calculation is the most critical part where errors cost money. Rule one: never store commission as a derived value, always as a fact. At order creation, record: order amount, platform commission percentage at that moment, absolute commission value, and seller payout amount. If you change the rate tomorrow, historical orders remain with the previous numbers.

Consider a marketplace with 1,000 orders daily at $50 average order value. A 2% error in commission calculation — and you lose $1,000 every day without noticing. Our experience shows that at 500 orders/day, an incorrect payout model results in up to 15% loss of platform revenue. We have solved this for 50+ projects, from niche B2B to horizontal retail. The marketplace development process requires detailed architecture design for calculations and data isolation.

Commission Models (we use one of or combine)

We use Stripe Connect as the baseline standard. Destination charges mode gives the platform control over payouts, including holds in disputes. Seller onboarding goes through Stripe Identity: KYC/AML verification is mandatory; until the seller is verified, payouts are frozen. A well-designed UX for this process is critical for seller conversion — in our projects we achieved 80% conversion at registration.

What commission model suits your marketplace?

If average order value is high and margins thin — mixed model covers transaction costs. For B2B with volume discounts — tiered works best. Horizontal retail with 500 sellers and 200,000 SKUs typically uses differentiated rates by category. The wrong model can cost 3–5% of GMV, which directly hits your bottom line.

Why Multitenancy Architecture Is Critical for Data Isolation

The first step is choosing a multitenancy architecture. In shared-schema mode, all sellers are in the same tables with vendor_id. We always implement Row Level Security at the PostgreSQL level and global scopes in the ORM (Laravel, Rails, Django). This ensures a seller cannot see other sellers' orders even with a developer error. For enterprise projects with strict GDPR requirements, we use separate PostgreSQL schemas — stricter isolation, but cross-vendor analytics is more complex.

How to Handle Inventory Without Race Conditions

Two buyers simultaneously add the last item to their cart. Who gets it? Use optimistic locking when creating the order:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Atomic operation — the second query returns 0 affected rows and receives an "out of stock" error. Typical schema for high-traffic marketplaces. Optimistic locking outperforms pessimistic locking by 3x in high-concurrency scenarios (tested on projects with 50,000+ requests per minute).

Comparison of Catalog Approaches

For a niche B2B marketplace, we often choose per-vendor — faster launch. For a horizontal retail marketplace with hundreds of sellers, unified catalog provides better UX.

Moderation Pipeline: Automated and Manual Verification

A marketplace is responsible for seller content. Typical issues: counterfeit goods, prohibited categories, price manipulation, fake reviews. We build a three-tier pipeline:

1. Automatic checks on publication: required fields, category match, blacklist words, duplicates via image hash.
2. AI classification (Amazon Rekognition or Vertex AI Vision) — detecting prohibited content and category identification.
3. Manual review queue for flagged items.

State machine: draft → pending_review → active / rejected → suspended. Each transition is an event with reason and moderator. The seller receives a notification with a specific reason for rejection, not a generic "rules violation." Review verification is mandatory — only after confirmed purchase. Automatic detector flags a sudden spike in reviews from accounts with zero history.

Search and Recommendations

Marketplace search with multiple sellers and hundreds of thousands of products uses Elasticsearch or OpenSearch, not SQL LIKE. Vector search for semantics, faceted filtering via aggregations. Personalized feed based on collaborative filtering. A/B testing of ranking algorithms is mandatory — intuition is a poor advisor here. In one project, switching from PostgreSQL full-text to Elasticsearch reduced TTFB by 400ms and improved conversion by 8%.

Marketplace Development Process

Marketplace development is iterative. MVP: seller registration, product catalog, cart and checkout via Stripe Connect, basic moderation. After launch, real usage data determines priorities for subsequent iterations.

Typical order:

• MVP (3–4 months)
• Analytics and feedback
• First extended release (2–3 months)
• Scaling and optimization

Timeline and Budget

• Marketplace MVP (catalog, checkout, basic seller profiles): 3–5 months.
• Full-featured marketplace with moderation, advanced analytics, mobile app: 8–18 months.
• Adding marketplace functionality to an existing e-commerce: 2–5 months.

Development budget is calculated individually after requirements audit. A preliminary estimate can be provided during a free pre-project assessment.

What's Included

• Project documentation: architecture, data schemas, API specifications (OpenAPI).
• Access to repository, CI/CD, deployment documentation.
• Training for the client's team on platform operation.
• Technical support for the first month after launch.

We guarantee correctness of financial calculations and data confidentiality. Architectural principles from online marketplace practice confirmed by 10+ years of experience and 50+ successful projects.

Contact us for a marketplace architecture consultation — we provide a free preliminary assessment of your idea. Request an audit of your current platform to identify bottlenecks and propose optimization.