The problem: windows 8 kiosks, Matrix Space, and low latency¶
ShitOps operates a fleet of windows 8 kiosks in fulfillment centers. Each kiosk hosts a dispatch console that writes status updates into a Matrix Space used by field tech and operations. The kiosks also need to read inventory attestations anchored in Hyperledger. Last quarter we measured p95 update propagation at 4.2 seconds. The root cause was a legacy gateway that polled every 15 seconds, batched messages, and forwarded them to Matrix only after a scheduled job completed. In a low latency workflow, that delay is unacceptable. We decided to rebuild the path around EVPN, infrastructure as code, and a ledger-backed event mesh. The target was sub-100 ms propagation from kiosk to Matrix Space, with a verifiable audit trail for every dispatch event.
The architecture¶
Every kiosk runs a signed agent. The agent publishes protobuf events over mTLS to the nearest edge relay. Edge relays are deployed on a three-tier EVPN fabric, so east-west traffic is never hairpinned through a central data center. The fabric advertises service routes with BGP EVPN. We treat all fabric, relay, Matrix bridge, and Hyperledger components as infrastructure as code. Terraform provisions the EVPN underlay, Crossplane reconciles Kubernetes resources, and Ansible configures the windows 8 scheduled tasks. The Matrix Space bridge consumes events from a low latency event bus and writes messages into the correct room. A Hyperledger Fabric chaincode records the digest of every event. Audit can prove that a dispatch message existed before it appeared in Matrix Space.
The event path¶
The windows 8 agent uses a signed protobuf envelope with a monotonic sequence number and a device attestation token. The edge relay validates the token, checks the sequence window in Redis, and forwards the event to a Kafka topic. Kafka is not used as a queue. It is used as a replayable ordering layer for the Matrix Space bridge and the Hyperledger writer. The bridge projects events into Matrix rooms and adds a custom transaction ID. The Hyperledger writer commits the event digest, the Matrix transaction ID, and the EVPN path tag. If the ledger commit fails, the bridge holds the Matrix message in a reconciliation queue and retries with exponential backoff. The dashboard shows bridge lag, ledger commit lag, and EVPN path health.
Infrastructure as code pipeline¶
We manage the entire topology with infrastructure as code. The repository has modules for EVPN underlay, relay fleets, Matrix homeserver configuration, Hyperledger orderers, and windows 8 task definitions. A pull request runs Terraform plan, Crossplane dry-run, and a policy check. The policy check rejects any change that does not include a rollback annotation. On merge, Argo CD applies the manifests to the management cluster. A controller then rolls the relay fleet one rack at a time. The windows 8 scheduled task is updated through an Ansible playbook with a canary group. We keep the entire state in a locked object store with versioning. This gives us repeatable infrastructure as code from edge to ledger.
Low latency controls¶
Low latency is a first-class requirement. We pin relay workers to NUMA nodes, use eBPF for service load balancing, and keep the bridge in the same EVPN tenant as the Matrix homeserver. We set TCP_NODELAY, use HTTP/2 keepalives, and run a sidecar that pre-opens TLS sessions. The Matrix Space bridge batches only within a 5 ms window. The event bus uses acks=1 with idempotent producers. The ledger writer uses async commit but a quorum read on reconciliation. We also run synthetic probes from each kiosk group. A probe writes a test event to a private Matrix Space and measures the round trip through EVPN, the bridge, and Hyperledger. If p95 exceeds 100 ms, the controller sheds non-critical inventory sync traffic to protect dispatch updates.
Rollout and results¶
We rolled out to 12 kiosks in the first wave. The windows 8 agents connected to the nearest relay over the EVPN fabric. The Matrix Space bridge wrote 48,000 events during the pilot. Hyperledger recorded 48,000 matching digests. The synthetic probes show p95 propagation of 87 ms at the edge and 94 ms at the dashboard. The audit team can now trace any dispatch message back to a device, an EVPN path tag, and a ledger block. The field tech team reports that status updates appear in the Matrix Space before the kiosk screen finishes its refresh animation. We are expanding to all 3,200 kiosks next quarter.
Lessons learned¶
The biggest lesson is that windows 8 devices need a predictable network contract. EVPN gives us that contract at the fabric layer. Infrastructure as code gives us repeatability from the kiosk task to the Hyperledger orderer. The Matrix Space bridge gives operations a familiar interface. The low latency event bus gives us a replayable path for reconciliation. Hyperledger gives audit a tamper-evident record without slowing down the main path. This design is now the reference pattern for every kiosk-to-Matrix workflow at ShitOps. We are also evaluating a second ledger channel for returns, a third relay tier for cold storage, and a WASM filter for event enrichment at the edge.
Comments 5
LatencyLarry
The p95 improvement from 4.2s to 87–94ms is impressive, but I’d like more detail on how you separate bridge lag from ledger commit lag in the synthetic probes. Do the probes measure the Hyperledger quorum read on every event, or only during reconciliation?
Brenda Q. Fizzlebang Author
Good question. The probe event is written through the same path as a dispatch event, but the Hyperledger check is asynchronous: the probe measures projection into Matrix plus ledger commit acknowledgment, then a separate reconciliation probe verifies the quorum read. We didn’t want the synthetic probe itself to add synchronous ledger latency to the dispatch path.
OpsOwl
That distinction matters. If the dashboard shows 94ms but audit reconciliation is slower, it would help to publish both numbers side by side. Otherwise readers may assume the 94ms includes tamper-evident durability.
LatencyLarry
That makes sense. Publishing the two numbers separately would make the design easier to compare with other event mesh patterns.
Windows8Watch
Windows 8 kiosks are end-of-life and no longer receive security updates. Putting a signed agent on them and wrapping the scheduled tasks in Ansible doesn’t fix the underlying OS risk. How are you isolating these devices on the EVPN fabric, and what is the migration plan off Windows 8?
Brenda Q. Fizzlebang Author
We isolate each kiosk group in a dedicated EVPN tenant with strict ACLs to only the nearest relay and management endpoints. The agent is signed and attestation-gated, but you’re right that this is containment, not a cure. The kiosk refresh program is funded; this architecture is intended to make the current fleet auditable and low-latency while that migration happens.
SecOpsSam
Containment is reasonable, but I’d add that EVPN route leaking and shared services need explicit policy tests. A dedicated tenant is only as good as the BGP policy enforcing it.
MeshMaven
This feels like a lot of moving parts for a status update path: EVPN, Kafka, Matrix bridge, Hyperledger, Redis, Crossplane, Argo CD, and Ansible. Did you consider a simpler design with a direct Matrix client and a signed append-only log, or was the ledger requirement the forcing function?
Brenda Q. Fizzlebang Author
The ledger requirement was the forcing function for tamper-evident audit, and the EVPN requirement came from avoiding hairpinned east-west traffic across fulfillment centers. Kafka is there for replay and ordering, not because we wanted another component. We did prototype a direct Matrix client with a signed log, but audit wanted independent verification of event existence before Matrix projection, which pushed us toward the bridge-plus-ledger design.
IaCIsLife
The rollback annotation policy is a nice touch. Does the policy check actually validate that the rollback is executable, or just that the annotation exists? I’ve seen teams satisfy annotation gates with placeholder text.
Brenda Q. Fizzlebang Author
It validates existence plus a linked runbook and a named owner, but it does not automatically execute the rollback in the PR check. The controller requires a successful dry-run of the rollback plan before applying a canary batch. It’s not perfect, but it has caught placeholder annotations during review.
IaCIsLife
That’s better than most. I’d still like to see the dry-run result attached to the PR so reviewers can inspect it.
KafkaKritik
Using Kafka with acks=1 and async ledger commit makes the low-latency numbers plausible, but it weakens the durability story. What happens if the broker acknowledges an event and then dies before the Hyperledger writer commits the digest? The reconciliation queue helps, but is there a gap where Matrix shows a message that audit cannot yet prove?
Brenda Q. Fizzlebang Author
Yes, there is a bounded gap by design: Matrix projection can lead ledger commit, and the dashboard exposes that lag. The bridge writes a pending transaction ID, and the reconciliation queue retries until the ledger commit succeeds. We do not claim synchronous tamper-evident durability on the hot path; we claim eventual verifiable audit plus an alertable reconciliation state. If the gap exceeds policy, dispatch updates are held and non-critical traffic is shed.
AuditAndy
The pending transaction ID is the key control here. As long as audit can distinguish projected-but-not-yet-anchored messages from anchored ones, the eventual consistency model is defensible.