Event security / Real-time software

Guest Check-in

One guest list. Multiple gates. A shared answer.

A guest check-in system for event security teams, bringing shared arrival records and coordinated gate operations into one staff-facing tool.

  • JavaScript
  • Supabase
  • PostgreSQL
  • Realtime
  • CSV imports
Staff-authenticated application
Comic illustration of event staff confirming a guest arrival
Editorial concept illustration of staff recording a guest arrival. The scene explains the workflow rather than reproducing the application interface.
2named entry gates
10,000generated guests in local benchmarks
3.04 msdocumented local median processing
The project in brief

Problem. Solution. Evidence.

The problem
Multiple gate operators need a consistent answer about who has arrived.
My solution
I combined server-controlled check-ins with targeted live updates and recorded gate history.
The evidence
Project documentation reports local median processing of 21.97 ms → 3.04 ms for 10,000 generated guests. Mocked transport and a stub DOM exclude real network, database, and rendering time.
The story of an arrival

From a name to a shared record.

Scroll through four steps. Concept illustrations bring each step to life.

Comic illustration of event staff searching for a guest on a tablet
01 / 04Find the right guest
01 / Find

A busy gate starts with a simple search.

Staff narrow the list by name and confirm the right person. A focused result helps the operator confirm the guest before recording an arrival.

Less scanning. More context.Comic illustration of event staff searching for a guest on a tablet
02 / Choose

The location belongs to the arrival.

The operator selects Back Gate before recording the next guest. Previous Main Gate arrivals retain their original location.

One list. A clear record of each gate.Comic illustration of staff directing a guest to the chosen entrance
03 / Confirm

A check-in becomes a traceable record.

Recorded arrivals show the time, gate, and staff member. In the application, a server-side row lock preserves the first successful check-in if two operators act on the same guest.

Keep the original record. Avoid duplicates.Comic illustration of staff confirming an arrival while a guest presents an invitation
04 / Share

Other staff can see what changed.

The application uses live notifications to refresh affected guest records. Attendance totals summarise recorded arrivals; they do not measure current occupancy.

Try the two-gate simulation below.Check in your first demo guest ↗Comic illustration of two gate staff sharing the same confirmed arrival
Try it yourself

Two gates. One shared guest list.

Find a guest and record an arrival at either gate. Watch both dashboards receive the same update.

Interactive simulation

Fictional guests · runs only in this page · no account or live database connection. The short sync delay illustrates the workflow; it is not a speed measurement.

The problem

Make the next step clear.

Developed with Martyn’s Law preparedness in mind, this project supports coordinated admissions and visibility of recorded arrivals. When two operators check the same guest at nearly the same time, server-controlled check-ins keep the record consistent and live updates share it with other staff devices.

How it works
  1. 01Find guest
  2. 02Confirm at gate
  3. 03Save on server
  4. 04Sync to staff
Inside the project

What the implementation does.

01

A check-in that stays consistent

A PostgreSQL function locks the guest row, returns the existing record if already checked in, and otherwise records the first successful gate, time, and staff member.

02

Tools for event administration

The project includes spreadsheet imports, separate list exports, staff management, attendance totals, and a related sports-roster workflow.

03

Recovery when connections change

Live notifications update affected guests. Full reconciliation and fallback refreshes help recover shared state; failed synchronisation disables changes rather than queueing offline admissions.

Security context

Supporting Martyn’s Law preparedness.

Designed to support event-security operations as part of wider Martyn’s Law preparedness. Shared check-in records and staff coordination are supporting tools; this project does not establish compliance with the Act or replace a venue’s public-protection procedures.

Read the official government guidance ↗

A technical decision

Refresh the guest that changed, not the entire list.

After a confirmed save, the client reads the affected guest. Live notifications are grouped briefly and larger batches fall back to a full snapshot. Session and request guards prevent older responses from overwriting newer updates.

Scope & reflection

What this demonstrates.

The documented benchmark reduced median local processing from 21.97 ms to 3.04 ms using generated guests, a stub DOM, and mocked transport. It excludes network latency, database execution, and browser rendering, and is not a measured end-to-end gate speed. Live multi-device field testing remains separate.

A useful next step

Measure tap-to-confirmation and cross-device propagation on actual gate connections using a dedicated fictional guest list.

Summary based on setup and performance documentation, client code, and the PostgreSQL check-in function.

Next projectCar Price Prediction