Aadhib

Case study · Active

Designing a booking platform with 30-minute slots, holds and staff operations

The booking form is a weekend's work. Holds, concurrency, arrivals that don't match bookings and the queue that forms when a session overruns are the actual product.

Role
Architecture and delivery
Published
Reading time
1 min
Next.jsPostgreSQLScheduling
01

Context

A consultation practice running fixed 30-minute slots has a public booking problem and an operational queue problem. They look like one problem and they are not, which is why booking software so often solves half of it.

02

Problem

Booking decides who has a slot. The queue decides what happens on the day — people arrive early, late, together, with family members who were not on the booking, or for a session that has overrun by twenty minutes. A system that models only the calendar produces a schedule that is confidently wrong from about 10am onward.

03

Constraints

01
Slots are finite and contested
Two people must not be able to take the same slot, including when one of them is halfway through a form.
02
The schedule and the room disagree
The calendar runs on planned time; the waiting area runs on real time. Both have to be represented without either lying to the visitor.
03
People arrive as groups
Family members turn up together whether or not the booking mentioned them.
04
Rescheduling is normal
It is a routine act, not an exception, and it should not destroy the appointment's history.
04

Approach

I used one appointment record behind two front ends. Booking places a hold while the form is being completed, then confirms. The appointment carries its attendees and its delivery mode. On the day, the same record moves through check-in, queue and completion — so the visitor's view and the staff's view are the same object read from opposite ends.

05

Architecture

Slot availabilityFixed 30-minute slots with short-lived holds during booking.
Appointment recordAttendees, delivery mode, state. One object, read by both the visitor and staff sides.
Day-of flowCheck-in, queue position, completion.
DisplaysPublic waiting display driven by the same queue state.
06

Solution

A booking flow with holds and confirmation, appointments that carry the people actually attending, first-class rescheduling that preserves history, and a day-of flow through check-in, queue and completion feeding a public waiting display.

The two-clock problem

Every appointment system has two clocks. One is the schedule, agreed in advance. The other is the room, which is always drifting. A design that only represents the first will tell a visitor their appointment is at 11:00 while they sit in a waiting area watching 11:20 go past.

Representing both honestly — you are booked for 11:00, you are third in the queue — is more work and considerably more useful.

07

Lessons

  1. 01Holds are a correctness feature, not a nicety. Without them concurrent bookings collide; with a window that is too long, availability looks worse than it is.
  2. 02Model the appointment, not the calendar entry. Attendees, delivery mode and state all belong to the appointment, and a calendar row cannot hold them.
  3. 03The queue is where booking systems fail publicly. Everything before the day is invisible to the visitor; the waiting room is not.
  4. 04Rescheduling as a first-class action preserves history that cancel-and-rebook destroys — and the history is what makes repeat visits work.

Stack

What it runs on

Application
Next.jsPostgreSQL
Scheduling
Fixed slotsSlot holdsRescheduling

The project

01Consultation booking platform
SYSTEM NOTEBuilding software for receptionists, guards, hosts and admins at the same time
All case studies