The Big Undertaking: Keycard-Free Entry

Photo: snehgohil · WordPress Photos (CC0 1.0), via Openverse

There are weeks in which you finish a feature, and there are weeks in which you open an entirely new category. This was the latter. Until recently, Xircuit was a platform that knows who is a member, what someone has booked, and how their training progress looks — but it had no control whatsoever over the physical door that same person walks through every morning to enter the studio. That exact gap was the biggest undertaking I've taken on so far.

The idea behind it is simple; the implementation wasn't: anyone with an active membership should be able to enter the building without a plastic card, without a chip, and without queuing at the front desk. The membership itself becomes the key. That sounds like a small extension, but in reality it's the point where software meets a piece of hardware that unlocks a door for the first time — and that leaves no room for approximate answers.

Why keycard-free is its own undertaking in the first place

Card systems have been standard for decades, and that's exactly their problem: they know no state. A card that has once been issued opens the door until it is physically blocked or collected. If a membership expires, a cancellation takes effect, or access is revoked for disciplinary reasons, enforcement hinges on a manual step at the front desk. In the worst case, days can pass between "canceled in the system" and "can no longer get in."

Contactless, keycard-free entry reverses that. The decision of whether someone may enter is no longer made on a piece of plastic, but at the moment the person stands in front of the door. The platform checks in real time whether the membership is valid at that exact instant, and only then releases the door. A membership that ends at midnight opens nothing at 6:01 a.m. — without anyone having to intervene. That is the real value, and it's also why the whole thing reaches so deeply into the architecture: an access decision must be neither too slow nor wrong.

Real time at the door: the first SignalR backplane

The technically most interesting part was the real-time chain. When someone stands in front of the door, the check must not feel like it takes a second, and it certainly can't depend on a background poller eventually getting around to the right record. Door events have to flow the moment they occur — the event at the door, the check in the backend, the release back to the hardware.

For this, Xircuit used an Azure SignalR backplane for the first time. Until now, SignalR — where it was used at all — ran within a single process; the platform never needed a backplane, because no feature had to coordinate multiple instances over a shared real-time bus. Access control changes that: door events can arrive on any given replica, and the response must reliably make it back to the exact connection the affected door is attached to. The backplane is the glue that holds that together across multiple container instances. In a horizontally scaled Aspire world, that isn't a nice-to-have, it's a prerequisite for real time staying real time under load.

Zones and automatic locking

A studio is rarely a single room with a single door. There's the main entrance, perhaps a separate class room, a wellness area, changing rooms, occasionally a 24/7 zone open only to certain plans. That's exactly what zone management is for: it governs who may go where, and when. A membership is therefore no longer just "valid" or "invalid," but tied to specific areas and time windows.

The flip side of granting access is automatic locking. If a zone is outside its opening hours, if a membership doesn't carry the right entitlement, or if access has been actively revoked, the door stays closed — without anyone having to collect a card. These two halves, access and locking, are deliberately the same decision viewed from two directions. There is no second code path that treats "deny" differently from "allow"; it is a single check whose result falls one way or the other. That makes the behavior predictable and the rules traceable.

Photo: Mike Wilson · StockSnap (CC0 1.0), via Openverse

Ten sub-steps, fifteen services, a dedicated worker

I don't want to pretend this was a weekend project. It was by far the most extensive expansion the platform has seen so far: ten sub-steps from the first data modeling to a working door release, and in the end the slice comprised fifteen services that have to work together. That spans everything from the API that issues access decisions, through the SignalR layer, to the services that manage zones, entitlements, and door states.

At its heart is a dedicated access-control worker. The access logic deliberately doesn't belong in the web host that renders pages, nor in one of the existing domain workers. Door decisions and door events have a different time and failure profile than everything else on the platform: they are latency-critical, they must not compete for the same resources with a slow report run, and they need a clear, isolated responsibility. That's why access control got its own process — fully in line with the rest of the integration and worker structure, in which every clearly bounded domain gets its own service. That it ended up being fifteen services is not an end in itself, but the honest consequence of a physical domain needing to stay cleanly separated from the digital one.

Gantner hardware and the boundary between software and door

Software alone doesn't open a door. For the physical part, Xircuit relies on hardware from Gantner — fittings and readers that are well established in the fitness and access-control space and that handle the actual mechanical release. My job wasn't to invent a door lock, but to reliably build the bridge between the platform's real-time decision and whatever Gantner does at the wall.

That boundary is also the most interesting spot for the coming weeks. Between the cloud decision and the Gantner fitting there always ends up being a piece that runs on-site at the studio — and that piece has to be handled with particular care, because it's tied to hardware and can't just be redeployed on a whim. For this week, the situation was: the chain stands on paper and in code; the real door is the next step.

Manageable, but behind a flag

As big as a slice like this is, it's just as important to roll it out in a controlled way. The entire access control therefore runs behind the feature flag Features:AccessControl and is off by default. No studio gets a live door control unasked; the feature only becomes active where it has been deliberately switched on and verified. That is the only responsible way to roll out a feature that, in the worst case, decides whether someone is standing in front of a locked door.

For setup, there's a set of management tools in the form of Set-*.ps1 scripts that configure doors and zones. Instead of setting up every door by hand through scattered database entries, configuration goes through traceable, repeatable scripts — the same pattern that has already proven itself for the platform's secrets and setup tooling elsewhere. Anyone creating a new zone or assigning a door does so through a script whose result is reproducible, not through a manual click path nobody can reconstruct the next time around.

What's next?

Next week: the on-device connector that connects the doors — and how we secure its auto-update. Right at the boundary between cloud and fitting that I wrote about above, it will be decided whether a clean architecture also becomes a lock that reliably unlocks.