The Cloud-Based Hall Booking System with Zero Double Bookings.

A hall booking system is a set of rules with a calendar on top. The calendar is what people see. The rules decide whether a request is allowed: what counts as a clash, when a hold stops blocking, which dates are closed and what each slot costs. Most double bookings are not caused by careless staff. They come from a rule nobody wrote down, or one that was written and never tested. This page sets out the rules, the tests that prove them and a clash checker you can run in Excel.

Start with the definition of a clash. Two bookings for the same hall clash when the existing one starts before the new one ends and ends after the new one starts. In plain words, the time ranges overlap. Adjacent bookings do not clash, so a lunch that ends at 3 pm and a meeting that starts at 3 pm can both stand. The classic off-by-one bug is writing 'less than or equal to' where 'less than' was meant, which blocks a slot that is actually free. The second bug is comparing dates and shift names instead of times. A full-day booking then looks different from a morning booking, and the system lets both in.

Weddings cross midnight. An evening function from 6 pm to 1 am ends on the next date. If the system stores only a date and the word evening, it cannot see that a request at 12:30 am on the 27th overlaps the function that began on the 26th. Store a real start and a real end and the problem goes away. In the workbook on this page, test 11 asks for 12:30 am on 27 November against a function that ends at 1 am and the answer is a clash. Test 12 starts at exactly 1 am and is free.

Buffers protect cleaning and set-up. Say a lunch function ends at 3:30 pm and the evening decor crew needs 90 minutes. The earliest a new booking may start is 5 pm, so a request for 4 pm has to be refused even though nothing overlaps on the calendar. The buffer widens the new range on both sides before the check. In the workbook, a 3 pm to 5 pm request that starts just as a confirmed morning function ends is free with no buffer and a clash with a 90-minute buffer.

A hold is a booking with a status and a clock. It blocks the slot for everyone until it expires, then it stops blocking on its own. Kaliquid's tentative holds expire after 48 hours. The cost of a lazy hold rule is easy to state. If 6 of your 20 prime slots in a season sit on holds that never convert, at Rs 1,80,000 a slot, that is Rs 10,80,000 of rent off sale for two days while a family thinks it over. A system needs the expiry, a reminder to the salesperson 24 hours before, and a way to see who holds the date. Tests 5 and 6 show a hold blocking a request and the same request passing after expiry.

Rules on paper are not enough if two people save at the same moment. A check followed by an insert has a gap, and both requests can see the slot free. There are two safe answers. Do the check and the insert in one transaction after locking the hall row, so the second request waits and then sees the first booking. Or let the database enforce the rule: in PostgreSQL an exclusion constraint on the hall and the time range refuses an overlapping row outright, and it needs the btree_gist extension. Either way, test it by opening one slot in two browsers and pressing Confirm together. Kaliquid describes its date lock as atomic, and that is the question to put to any vendor: what happens in the second before two saves land?

Prices are rules too. Take a base rent of Rs 1,20,000, with a weekend 20% higher, a peak month 30% higher and a muhurat date 50% higher. If the rule is that the highest premium applies, a muhurat weekend in peak season costs Rs 1,80,000. If every premium multiplies, the same date costs Rs 2,80,800, which is Rs 1,00,800 more, and the client sees a number that nobody in the hall can explain. Pick a rule, publish it with the rate card, and add GST as a separate line after the premium at the rate for the booking type.

If you are building a hall booking system as a college project, the same rules apply, and these are the parts worth showing in the report: tables for halls, bookings, blackouts, payments and an audit log, the overlap query with a buffer, holds that expire, and the two tests a spreadsheet cannot run, simultaneous saves and time zones. The Word document on this page has the tables, the SQL and the test plan, and the workbook has the twelve tests. If you run a real hall, use the same two files to brief a developer or to check a vendor's demo. Kaliquid Pro is Rs 999 a month per hall, or Rs 750 a month billed yearly, with Enterprise priced by quote, and it is a finished system for Indian halls, not a coursework template.