Custom Scheduling Systems: Calendar, Bookings, and Dispatch

Scheduling Is a Harder Problem Than It Looks

Everyone has used a calendar app. Everyone has booked an appointment online. The familiarity breeds a dangerous assumption: scheduling software must be straightforward to build.

It is not. Scheduling systems deal with time — and time is one of the most deceptively complex domains in software engineering. Time zones, daylight saving transitions, recurring events, conflict detection, resource constraints, cancellation policies, buffer times, multi-party coordination. Each of these is individually manageable. Combined, they produce a system with a surprising number of edge cases.

I've built scheduling systems for service businesses, healthcare providers, and field service operations. The lessons are consistent across domains: the data model matters enormously, time zone handling must be correct from day one, and the conflict detection algorithm is the heart of the system.

The Data Model That Handles Reality

A scheduling system has three core entities: resources, time slots, and bookings.

Resources are the things being scheduled. A technician. A conference room. A piece of equipment. A resource has availability — the times when it can be booked — and constraints — the types of bookings it can accept, the maximum concurrent bookings, the buffer time between bookings.

Time slots represent available windows. For simple systems, slots are pre-defined: 9:00-9:30, 9:30-10:00. For flexible systems, availability is defined as ranges and the system calculates available slots based on existing bookings and constraints.

Bookings are commitments of a resource to a time window for a purpose. A booking has a status lifecycle: requested, confirmed, in-progress, completed, cancelled, no-show. Each status transition has business implications — a cancellation within 24 hours might incur a fee, a no-show might trigger a follow-up workflow.

The relationship between these entities determines your system's flexibility. A one-to-one model (one resource per booking) is simple but doesn't handle scenarios where a booking requires multiple resources — a medical appointment needs both a doctor and an exam room. A many-to-many model (a booking can reserve multiple resources, a resource can participate in multiple concurrent bookings) handles more scenarios but makes conflict detection more complex.

For dispatch-oriented systems — field service, delivery, mobile technicians — the model adds a geographic dimension. Resources have locations or service areas. Bookings have service addresses. Route optimization and travel time between appointments become part of the scheduling logic. This is where scheduling systems start to overlap with operations research.

Time Zones: Get This Right or Get Nothing Right

Every scheduling system that serves users across time zones must store times in UTC and convert to local time for display. This is non-negotiable. Storing times in local time creates ambiguity that will corrupt your data.

But "store in UTC, display in local" is only the beginning. The real complexity comes from a few specific scenarios.

Recurring events across DST transitions. A weekly meeting at 2:00 PM Eastern happens at a different UTC offset in January (EST, UTC-5) than in July (EDT, UTC-4). If you store the recurrence as "every Monday at 19:00 UTC," the meeting shifts to 3:00 PM local time when clocks spring forward. The correct approach is to store recurring events in the resource's local time zone and compute the UTC equivalent for each occurrence.

Bookings across time zone boundaries. A customer in Pacific time books a technician in Eastern time. What time zone does the appointment display in? The answer depends on context: the customer sees it in their time zone, the technician sees it in theirs, and the system stores it in UTC. Your API must accept a time zone parameter for display purposes while storing the canonical time in UTC.

Business hours in local time. A business that's open 9-5 Eastern is open 9-5 Eastern year-round, regardless of DST. Business hours should be stored as local time with a time zone identifier, not as UTC offsets. Use the IANA time zone database (America/New_York, not EST or UTC-5) to handle DST transitions correctly.

Conflict Detection and Availability Calculation

The core algorithm of any scheduling system answers one question: given a resource and a proposed time window, is the resource available?

For simple cases, this is a database query: find any existing bookings for this resource that overlap with the proposed window. Two time ranges overlap if the start of one is before the end of the other and vice versa. Include buffer times in the overlap calculation — if a resource needs 15 minutes between bookings, extend each existing booking by 15 minutes when checking for conflicts.

For systems with recurring bookings, conflict detection gets more expensive. You need to generate the occurrences of each recurring booking within the query window and check each one for overlap. Materializing recurring occurrences into a separate table (pre-computing the next N occurrences) trades storage for query performance and is usually worth it.

For multi-resource bookings, conflict detection must check all required resources. A booking that needs a doctor and an exam room can only be scheduled when both are available simultaneously. This is a constraint satisfaction problem, and for systems with many resources and constraints, it can benefit from the optimization techniques used in enterprise integration patterns.

Availability calculation is the inverse of conflict detection: given a resource and a date range, what time slots are available? This involves starting with the resource's availability template, subtracting existing bookings (including buffers), subtracting blocked times (holidays, maintenance windows), and returning the remaining windows.

For customer-facing booking interfaces, the availability calculation runs on every page load and needs to be fast. Caching the availability for the next N days and invalidating on booking changes is a common optimization.

Beyond the Calendar: Dispatch and Optimization

Dispatch-oriented scheduling adds a layer of optimization on top of basic availability. When a customer requests a service appointment, the system doesn't just find an available technician — it finds the best available technician based on skills, location, travel time, workload balance, and customer priority.

This is where simple database queries give way to scoring algorithms. Each candidate technician gets a score based on weighted factors: proximity to the service location, matching skill set, current daily workload, customer preference for a specific technician, route efficiency relative to their existing schedule. The highest-scoring technician gets the assignment.

Real-time dispatch — reassigning technicians as conditions change throughout the day — adds another dimension. A cancelled appointment frees up a slot that might be better used for a different job. A technician running late cascades delay to their subsequent appointments. These systems need to continuously re-evaluate the schedule and surface recommended changes to dispatchers.

The architecture for dispatch systems benefits from the same domain-driven design principles that apply to any complex business domain. The scheduling bounded context has its own language (slots, availability, conflicts, assignments) and its own rules that shouldn't leak into the rest of the application.

If you're building a scheduling or dispatch system, I'd be happy to talk through the architecture.