Waqar Ul Wahab
ALL PROJECTS/CHANDNI BANQUET HALL

Overview

The public half of the site markets the venue: the rooms, the photography, the enquiry form. The working half sells it.

A visitor picks a hall and a date, and the page asks the server what is still open. The answer is derived on the spot from the bookings that already hold that date — there is no availability flag anywhere. Eight three-hour slots tile the day, and a booking can hold one of them, several, or all of them.

Step two adds menu items as line items with their own quantities, and the running total is the hall's hourly rate across the slots held plus the food. Step three writes the booking under a UUID, sets it pending, and takes a 25% deposit by card. The balance follows later through a payment link that carries its own expiry.

Behind it, the venue's staff work the framework's own admin — eleven registered screens covering bookings, payments, halls, menus, photography and enquiries.

Problem

A banquet venue's real product is a room on a date, and the thing that costs it money is double-booking one.

Run that by phone and pencil and the person answering has to hold the whole diary in their head: quote a price off a rate card, remember which enquiries turned into deposits, and chase the balance before the event arrives. Every one of those is a place for the diary and reality to come apart.

The obvious software answer — a calendar with an availability flag on each date — quietly makes it worse. The moment a booking is cancelled, edited or half-written, the flag and the truth disagree, and nobody finds out until two families turn up for the same afternoon. Any design that stores availability needs a second mechanism to keep that store honest, and that second mechanism is exactly the thing that falls behind.

So the system had to make that failure structurally impossible, while still being simple enough for a small team to run from a back office nobody had to train them on.

System Design

How It Works

01/04
01

Asking what is still open

The one mechanism the whole system rests on — availability is a question answered from the bookings, never a flag read off a calendar.

  1. 1The visitor picks a hall and a date; the page calls the availability endpoint with just those two values
  2. 2The server loads the bookings that already sit on that hall and date and are not cancelled
  3. 3It collects the slots those bookings hold, treating a full-day booking as holding all of them
  4. 4It returns the eight slots split into available and taken, and the page renders them as selectable or not
  5. 5Because the answer is derived, a cancelled booking releases its slots the instant it is cancelled — nothing has to be written back
  6. 6And because a slot is an identity rather than a time range, two bookings can be compared without any overlap arithmetic
02

Building a booking in three steps

One page, three stages, and a gate on each — an impossible booking cannot be assembled.

  1. 1Step one takes the hall, the date, the slots, the guest count, the event type and contact details, and stays locked until a slot is actually held
  2. 2The hall panel fills in from the venue record — capacity and hourly rate — and the pricing summary starts totalling as slots are ticked
  3. 3Step two offers the menu as a form-set: many items, each with a quantity, each contributing its own line to the total
  4. 4Step three replays the whole booking for review and takes the terms acceptance
  5. 5On submit the server writes the booking with a fresh UUID, links its slots, writes one row per menu line, and sets it pending
  6. 6The customer lands on a confirmation keyed by that UUID, and the same reference carries through every email and payment that follows
03

Deposit now, balance later

Money arrives in stages, and the record stays coherent at every point in between.

  1. 1A 25% deposit is quoted straight from the booking total and taken by card
  2. 2The charge is recorded as a payment in its own right, carrying a type — deposit, balance or full — and a status
  3. 3The booking's paid amount rises, and the remaining balance is derived from it rather than stored separately, so the two can never disagree
  4. 4A confirmation email goes out from a template, after the booking is already written, so a mail failure costs the message and not the booking
  5. 5For the balance, staff generate a payment link that carries an expiry, and the link is emailed to the customer
  6. 6Opening the link checks that expiry first, so a lapsed hold stops being payable rather than quietly taking money
04

How the venue works the diary

The staff side is the framework's own admin, on purpose — eleven screens instead of a console nobody asked for.

  1. 1A new booking lands as pending and appears in the back office alongside its payments
  2. 2Staff confirm it once the deposit has cleared, moving it through the four-state pipeline
  3. 3The same back office maintains the halls, the eight time slots, the menu catalogue and the gallery, so the public site is edited without a deploy
  4. 4Contact enquiries and newsletter subscribers land in the same place, so nothing arrives in a separate inbox
  5. 5After the event the booking is marked completed, and it drops out of the availability calculation for good
  6. 6A booking cancelled at any point simply stops counting toward availability — the diary corrects itself

Key Features

  • Live availability for any hall and date, computed from existing bookings — eight three-hour slots render as free or taken, with a running count of total, available and booked
  • A three-step booking wizard on one page — choose hall and date, select menu, review and confirm — where each step unlocks only once the previous one holds real data
  • Multi-slot bookings: an afternoon, an evening, or the whole day, priced as the hall's hourly rate across every slot held
  • Menu selection as a form-set — many items, each with its own quantity — with the line totals folded into the booking total as it is built
  • Six event types and four booking statuses, so a wedding, a corporate evening and a baby shower move through the same pipeline with the right labels
  • Staged payment — a 25% deposit to hold the date and a remaining balance later, both derived from one stored pair of amounts
  • Expiring payment links, emailed to the customer, checked for expiry at the moment they are opened
  • Guest booking alongside signed-in booking — with no account, the booking carries its own contact details; with one, it joins a personal booking list where a pending booking can still be cancelled
  • Three templated transactional emails — booking confirmation, payment link and payment receipt — each sent as HTML with a plain-text alternative
  • A back office on the framework's own admin: eleven registered screens covering bookings, payments, halls, time slots, menus, photography and enquiries

Outcomes

  • Double-booking is designed out rather than guarded against — availability is computed from the bookings themselves, so there is no flag that can drift out of step with the diary
  • Cancellation costs nothing to process: a cancelled booking releases its slots by definition, with no compensating write and no cleanup job to fall behind
  • A date is held by money, not by a promise — a 25% deposit is taken at the point of booking, and the balance follows through a link that expires rather than lingering
  • The venue got a back office on day one without a line of console code: eleven admin screens covering bookings, payments, rooms, menus and photography
  • Nine migrations on the booking model trace the system growing up in place — free-form times becoming fixed slots, payments gaining links and expiries, and guest booking arriving without breaking the accounts that came before

More work