Turnstile and access control system

The problem

Entry to the palaces and museums relied on staff checking tickets by eye. Queues built up on busy days, a paper ticket could be reused or copied without anyone noticing, and the number of visitors inside was only known at the end of the day.

My role

Sole developer from analysis to go-live: architecture, the gate service running at each turnstile, the central ticket API, the database and the turnstile hardware integration (readers, relay, “turned” signal).

The solution

The visitor scans the QR code on their e-ticket, or their ID card, at the turnstile reader. The gate service sends the reading to the central ticket API, which validates the ticket. On approval the service fires the relay and the arm unlocks.

An entry only counts once the arm has actually turned. The turnstile reports the “turned” signal back and the entry record is committed at that moment, so a ticket that is scanned but not used is not consumed.

Outcome

• Manual checks at the gate disappeared, ticket reuse was blocked, and the number of visitors inside became visible in real time.

The hard parts and the decisions I made

When does a ticket count as used?

The obvious answer is the moment it is validated. But then a visitor who scans and changes their mind, whose arm jams or who steps back loses the ticket and is stuck at the gate. So I separated validation from commitment: on validation the ticket is briefly reserved, and the entry is committed when the turnstile sends its “turned” signal. If the signal never comes, the reservation lapses and the ticket can be used again.

One ticket, two gates, the same second

A copied QR code can be scanned at two turnstiles almost simultaneously. The reservation is a single conditional step in the database, so only one of the two requests wins and the other is rejected, with no extra locking and no gate-to-gate communication.

Repeated requests

When the gate service gets no reply, it resends the same event. Every entry event carries a unique ID and the central service is idempotent: the same event arriving twice still counts as one entry, and reports stay accurate.

Keeping hardware apart from business rules

The part that talks to readers and relays lives in a thin service at the gate; ticket rules live centrally. Changing a rule never means touching the turnstiles, and a different device only needs the gate service adapted.

What I learned

With hardware-bound software the real problems show up at the gate, not in the office: the rhythm of a crowd, a jammed arm, a dim phone screen, a ticket held upside down. A flow that works perfectly on a desk is tested in its first hour on site, so I learned to put field testing in the middle of the work, not at the end.

Technologies

• Backend: C#, .NET Core, REST API
• Database: SQL Server
• Hardware: QR and ID card readers, relay-controlled turnstiles
• Integrations: Central ticketing platform, handheld terminals, box office