The venue gate is a distributed system

For three years I worked the gate at Die Bosveld, an events venue in Pretoria — first running check-in on the venue's scattered, disconnected systems, then helping replace what I was operating. We built the replacement on Bubble with Gerhard van Staden; my job was knowing exactly what the gate needed, because I was the gate. Standing there is the best requirements workshop I've ever attended: every design flaw becomes a queue of impatient people looking directly at you.

Two marshals, one ticket

Die Bosveld runs one gate, but busy days put several marshals on it, each holding a phone — and sooner or later one ticket gets presented on two phones within seconds. Sometimes it's fraud; mostly it's a family that split up in the queue. Either way, if the system checks a ticket's status and then updates it as two separate steps, two simultaneous scans can both see "valid" and both admit — the same read-then-write race that bites databases, except the symptom is two marshals arguing an arm's length apart.

The rule we specified: every scan gets recorded with a verdict against the order's full scan history, and the history is what decides — not a status flag someone flips. A second scan of a used ticket bounces no matter whose phone catches it, and the record of both attempts survives for the inevitable dispute — settled at the gate, from the history, not at the office on Monday.

Families don't arrive as a unit

A day pass covers, say, four adults and six children — and families do not walk in as an atomic transaction. Dad enters with two kids; mom follows twenty minutes later with the rest. So the gate tracks what remains on a pass per visitor type and admits partial groups across multiple taps, rejecting only what exceeds the allowance.

That rule didn't come from a spec document. It came from watching marshals wave families through when the software said no — because software that fights common sense loses, and then your attendance data is fiction. If the people operating your system are bypassing it, the bug is yours.

Fallbacks are the feature

Check-in runs on ordinary phones: QR codes read by camera, NFC bracelets tapped against the phone, and customers can program their own NFC tag from their ticket page. Every one of those has a failure mode — old phones without NFC, cracked cameras, glare on a screen at noon — so every path has a fallback, down to "copy the link." At a gate, the fallback isn't an edge case; it's Saturday.

The admin doesn't work weekends

There was one more single point of failure, and it wasn't software. Under the old setup every exception — a wrong booking, a missing ticket, someone insisting they paid — queued behind one person: the admin. And the venue's busiest days are weekends and holidays, which is exactly when that one person is most often unavailable. Peak load, coordinator down, everything exceptional stalls.

The fix was pushing authority to the edge. Every marshal's phone can now look up and fix a booking, sell a ticket, take a payment, and settle a dispute from the scan history — the admin's powers, standing where the problem is standing. Past the gate there's a trailhead, and the worker there has the same access: whoever slips through gets caught and sorted out on the spot, and a used ticket bounces there too, because the history decides, not the person. A second checkpoint costs nothing when it runs the same state.

Check-in got drastically smoother for it — smooth enough that the gate needs fewer marshals than it used to, and nothing waits for Monday.

What this taught me

Operate the thing you help build, even briefly. The scan-history rule, the partial-family rule, the fallback chains, the admin's powers on every phone — none of them are visible from a desk. They're visible from the gate, at 09:00, when the queue is forty people deep. The spec I carry into everything I've built since is three years of Saturdays.

---

The full case study, numbers included: Die Bosveld Ticketing.