The rule this chapter follows

What was built with, and why

The two choices worth defending out loud

The database, six tables

Deliberately small. One design decision carries the entire research, and it is the fourth table.

Why table 4 is the thesis written as a schema

Access control, enforced by the database

Instead of the website hiding things people should not see, the database itself refuses to hand them over. This is called row level security.

The four features that are the contribution

Chapter 5 documents these four and deliberately skips routine things like registration and login, because those introduce no logic specific to this research.

1. The unified information layer

This is not a component you can point at on a screen. It is the property that the event's schedule, price, inclusions and live remaining availability form one record, read identically by the guest deciding whether to come and by the organiser deciding how much to buy.

Three decisions make it real:

• The one inventory table, so availability lives in one place
• The remaining count is only ever written by the booking function, so it cannot drift away from the bookings that produced it
• Both screens subscribe to the same table, rather than to separate copies of it

2. The multi-resource inventory model

An organiser defines any number of resources on an event, each with a kind, a name, a price and a total quantity. Remaining starts equal to total, and after that only a booking changes it.

One validation rule protects a guarantee rather than a field: you may reduce a total, but never below the quantity already booked. Allowing that would create an oversell through configuration instead of through concurrency. The rule runs inside the same transaction as the update.

Events also carry a capacity ceiling that applies across all ticket-kind resources, which is the space and safety limit organiser item 13 identified.

3. Atomic multi-resource booking

This is the feature with the greatest technical risk and the clearest correctness requirement.

So the check and the decrement happen inside one database transaction, called as a single operation. The website never reads availability and then writes it.

create_booking(event, items) returns booking

  begin transaction

    -- claim every resource row involved, in ascending id order
    select * from resource_types
      where id in (the requested resources)
      order by id
      for update

    -- check each requested quantity against the claimed figures
    for each item:
        if remaining_quantity < requested quantity:
            raise INSUFFICIENT_STOCK(name of that resource)

    -- check the event capacity ceiling across ticket-kind resources
    if already booked tickets + requested tickets > event.capacity:
        raise CAPACITY_EXCEEDED(the capacity)

    -- commit the whole booking, or none of it
    for each item:
        update resource_types
          set remaining_quantity = remaining_quantity - quantity

    insert into bookings   (with a random qr_token)
    insert into booking_items (one row per item, price copied in)

    return booking

  commit

4. Live availability propagation

The organiser dashboard and the traveller event page both subscribe to changes on the inventory table, filtered to the events in view. When a booking commits, the database publishes the row change and every subscribed screen gets the new number, with no polling and no refresh.

The subscription runs from the browser straight to the database service, rather than through the website's own server, so the update does not wait on an extra round trip.

QR validation at check-in

Every confirmed booking carries a token behind its QR code. It is a long cryptographically random value, not a sequential number and not a scramble of the booking id. A guessable token would let somebody get in without a booking, which is the ticket fraud problem Chapter 2 identified.

At the door, staff scan or type the token, and there are exactly three outcomes:

1. Unknown, or belongs to another eventRefused, with the reason shown.
2. Already checked inRefused as a replay, and the original check-in time is displayed so staff can see when it was first used.
3. Valid and confirmedAdmitted. Status set to checked in, timestamp recorded, and the booking contents shown so staff know what the guest has paid for.

What the system was seeded with

Seeded with partial availability rather than full stock, on purpose. A system tested only against untouched inventory never reaches the boundary conditions that matter. And no real person's name, phone number or email appears anywhere in it, which ties back to the ethics commitments in Chapter 3.

If they ask you

Why did you put tickets, rooms and add-ons in one table?

Because they differ in what they represent to a guest but behave identically to the system. Each carries a price, a total quantity and a remaining quantity, and each must be decremented atomically when booked.

One table produces three properties the alternative does not: a single query returns the complete resource position for an event, a single realtime subscription keeps every surface consistent, and a single locking discipline governs all concurrent decrements.

Modelling them separately would have fragmented availability across three code paths and reintroduced, inside the system, the same inconsistency between information sources that the research identifies as the primary failure of the manual arrangements it replaces.

Why PostgreSQL rather than MongoDB or another document store?

Because a booking must decrement several independent resource counts and either succeed completely or leave no trace, which requires transactional guarantees a document store does not provide by default.

Chapter 2 identifies concurrency control over multi-resource inventory as the central algorithmic problem for platforms of this type, and one reviewed source specifically finds that platforms operating on eventually consistent stores expose stale availability to users. Stale availability is the exact failure this research exists to eliminate.

Why is the booking logic in the database instead of in your application code?

So that correctness does not depend on client behaviour or on the number of running application instances. If the check and the decrement were done by the website, two copies of the website running at once could each make a correct-looking decision on stale data.

Inside the database, the rows are locked for the duration of the transaction, so there is no window between checking a figure and changing it. The client makes one call and either gets a booking or gets a named refusal.

Why is your access control in the database rather than in the interface?

Two reasons. First, a defect in the interface then cannot expose one property's booking data to another, because the interface is not what withholds it. Second, it makes the guarantee testable independently of the user interface, which is what TC-09 does by issuing requests directly against the API with one user's credentials against another user's data.

It also answers something the data asked for. Security and data protection appeared in 46.7 percent of substantive organiser adoption responses, ranking third among all conditions.

What is not documented in this chapter, and why?

Account registration, authentication and profile management. They are implemented using standard patterns and introduce no logic specific to this research, so documenting them would add pages without adding anything checkable.

The four features that are documented are the ones that constitute the technical contribution: the unified information layer, the multi-resource inventory model, atomic booking, and live availability propagation.