A gate, not a kill switch

28 July 2026architecturefleet

A gate, not a kill switch

Cutting off a device that should not be streaming is the easy half. The hard half is making sure it cannot come back — and that is a different mechanism.

Sample post. This is placeholder editorial used to build out the blog — the layout is real, the article is not published, and it is excluded from the feed and from search.

Every platform that streams from hardware eventually needs to stop one. A device is sold, a contract lapses, a key leaks, a camera moves to a customer who no longer pays for it. The obvious answer is a kill switch: find the live session, tear it down, done.

The obvious answer is also the half that does not hold. A device whose session you tore down is a device that reconnects four seconds later.

Two mechanisms doing two jobs

We separate them deliberately.

The gate sits between a connecting device and the control plane, checking key validity, entitlement and room binding; it either admits the device or refuses it outright. Below, on a separate lane, the kill acts on a session already in flight and is marked best-effort. — The gate decides whether a session can exist. The kill only ends one that already does.

The gate runs when a device connects. Before a device is allowed onto the control plane at all, it is checked: is this key still valid, does this Organization still have an entitlement, is this device still bound to a room it may serve. A device that fails is not connected, so there is no session to tear down.
The kill is what happens to a session already in flight. It publishes a disconnect on the control channel and cleans up the accounting behind it.

The kill is cooperative and best-effort. The gate is the guarantee.

If those two are the same mechanism, you have a race you cannot win: every teardown is followed by a reconnect, and whether the device stays down depends on which of the two arrives first.

Why this shows up in the product

Because the gate runs at connect time and reads current state, the things an operator actually does — deactivating a device, rotating a key, moving a camera out of a room, cancelling a plan — take effect without anyone chasing sessions around the network. The enforcement point is one place, and it is the place every device has to pass through anyway.

It also means the guarantee does not depend on the broker. Kicking a live session is a broker-specific capability and not every broker has one; refusing a connection is something every broker does, because it is the thing brokers are for.

The part that is genuinely harder

A device that is mid-move is live in the room it actually reached, not the room you last told it to go to. Those two can differ for as long as it takes a device on a patchy link to acknowledge an instruction — which on a truck, a boat, or a construction site can be a while.

So a disconnect has to target where the session really is. Aiming at where the device was supposed to be produces the worst possible outcome: an operation that reports success and changes nothing.