How to Handle Discovery and Delivery Windows in a Service Marketplace

Discovery and delivery windows in a service marketplace are two different problems that fail together. Discovery is how a customer finds a provider who can do the job, while a delivery window is the committed time slot when that job happens. You handle both correctly by giving each its own subsystem, then connecting them through a single bookable offer.

The two subsystems behind every booking

A service marketplace that handles real jobs, whether plumbing, tutoring, dog walking, or consulting, contains two separate parts under one product surface. The first is a search pipeline. It takes a customer's category, location, price range, and preferred date, then returns a ranked list of providers. The second is a scheduling engine. It decides which provider has capacity and turns a selection into a locked, confirmed job.

The search pipeline is backed by a search index, which is a data structure that lets the platform retrieve matching providers quickly without scanning every profile. The scheduling engine is backed by a booking state machine, which is a model where each job moves through defined states such as available, held, booked, in progress, completed, and cancelled. These two subsystems read some of the same data but have opposite performance goals.

Search is allowed to be a few minutes stale. Scheduling is not, because it ends in a database transaction, a group of operations that must all succeed or all fail so that data is never half-written. If you mix the two concerns, search speed suffers inside the transaction and availability errors leak into results. Customers then see a provider as free when that provider is already booked, and that mismatch is the most common source of marketplace support tickets. Roughly 30 percent of support tickets in a typical service marketplace relate to scheduling conflicts and missed windows; treat that figure as a planning estimate, not a measured constant.

Because the boundary is delicate, many teams commission a service marketplace platform with a scheduling core built for their specific job types rather than a generic template. The rest of this article explains how to design that boundary well.

What is a delivery window in a service marketplace?

A delivery window is a committed interval of time during which a provider promises to deliver a service to one customer. It is not a wish, and once booked it blocks that provider's capacity.

A delivery window has a start time, an end time, a provider, a customer, and a location. Some windows are exact appointments, where the provider starts at a fixed minute, while others are ranges, where the provider can arrive at any point inside the interval. The booking engine must distinguish these cases because they trigger different reminder and dispatch logic.

The window also needs a buffer. If a job tends to overrun, the next job starts late, and late starts cascade through the rest of the provider's day. A useful practice is to store a planned buffer of 15 to 30 minutes between windows for services where on-site time is variable. That buffer absorbs overruns without forcing a rebooking.

The delivery window is only part of the offer the customer pays for. When a customer books, they are buying a provider, a start window, a scope of work, and a price as one package. That package must be created atomically, meaning in one operation that succeeds or fails completely, or you can end up with a payment and no appointment.

How does discovery decide which providers are eligible?

Discovery should only return providers with open delivery windows suitable for the customer's requested date, time range, and commute distance, and it should never promise exact availability at search time. Schedules change between the moment of search and the moment of checkout.

There are two technical approaches to eligibility. The first is a live check, where the search handler asks the scheduling engine, for each provider in a shortlist, whether a compatible window is open. The second is a precomputed snapshot, where availability data is built periodically and served from the search index. Live checks are more accurate and cost more under load, while snapshots are fast and go stale. Most marketplaces run a version of both: a snapshot for ranking and a live verification during checkout.

Use these criteria to decide which approach fits your marketplace:

• Update frequency: if providers change calendars several times a day, a snapshot older than 15 minutes will mislead customers.
• Volume and latency: a live check against dozens of candidate providers can add hundreds of milliseconds to a search, so budget your response time.
• Failure tolerance: search can tolerate temporary staleness, while checkout cannot tolerate a double booking.
• Operational complexity: snapshots need a background job and a refresh schedule, while live checks need a scheduling engine that handles concurrent reads.

The comparison table below shows the three common scheduling models and how they affect eligibility.

After the customer sees eligible providers, the discovery pipeline hands the chosen offer to the scheduling engine, whose only job is to protect the window from double booking. If you are building a service marketplace platform rather than adapting a generic template, expect two to four weeks of work on the scheduling core alone, before payment and notification features are added.

How do you prevent double booking of a delivery window?

Hold the slot and then book it inside a single database transaction, so two customers can never both take the same window. The transaction should mark the slot as held when checkout starts and confirm it when payment succeeds.

Double booking happens when two reads see a slot as free before either write. The standard defences are pessimistic locking, where the system locks the slot row when a customer opens checkout so nobody else can see it, or optimistic locking, where each slot carries a version number and the system rejects a write if another customer changed that version first. Pessimistic locking suits checkout flows that last a few seconds, while optimistic locking suits mobile and offline clients where a network failure cannot leave a row locked forever.

A common pattern is a short hold. The customer enters checkout, the system reserves the window for 10 to 15 minutes, and the hold expires if the customer does not complete payment. Many teams plan for around 20 percent of checkout carts being abandoned, so holds must expire; otherwise providers look permanently busy.

You also need idempotent booking requests, which means a request that can be sent twice with the same effect as sending it once. The booking runs over an API, an application programming interface through which the checkout app talks to the booking server. If the customer's payment network times out and the app retries the request, the booking service must recognise the duplicate and return the same booking instead of creating a second one.

Why do delivery windows fail in production?

Delivery windows fail because a provider cannot honour the commitment, a customer is not ready, or the platform held the wrong data from the moment of booking. A robust marketplace treats failure as normal and designs a recovery path.

Provider-side failures include overruns from the previous job, vehicle breakdowns, and bookings that the provider double-booked outside the platform. Customer-side failures include wrong addresses, missed arrival notifications, and jobs where the customer booked the wrong service. Data failures come from time zone mistakes, stale eligibility, and windows that were never truly open.

Time zones deserve special attention. If the provider works in a zone different from the customer, store every time in a canonical form, a single standard form such as UTC, the coordinated universal time standard used as a common reference, and convert only for display. Storing local times without a zone is a reliable way to create no-shows and support tickets.

A practical recovery workflow has three components. First, automated reminders sent 24 hours before and again 2 hours before the window, by push notification or SMS. Second, a reschedule flow that lets either side move a booked window without losing the payment record. Third, an exception report that shows which providers have the highest missed-window rate, so operators can intervene early. Roughly 5 to 15 percent of service appointments will miss their window even in a well-run marketplace, so invest in recovery rather than in perfect prediction.