Real-Time Check-In System

01 — CONTEXT

On the California State Senate Floor, the team supporting Floor Sessions keeps track of floor attendance as a session runs. That tracking is critical: an accurate quorum is needed before a Floor Session can begin. At the time, that happened the manual way: status was called in over the radio and logged on paper, a process that was hard to audit, slow to report on, and easily out of date. They needed it digitized into a real-time system across multiple tablets, where a change made on one device appears on all of them immediately.

Because attendance lived across separate radios and each person's own notes, no two of them held the same picture. A status known to one of them reached the others only when it was called in and written down, so the records were always a step behind. That delay was the gap the system was built to close.

Keeping everyone on the same live picture ruled out a standard request-and-response page, which only updates when someone reloads. The system had to push state to every tablet the moment something changed, not wait for the next refresh.

02 — SOLUTION DESIGN

The design brought in new technology only where it earned its place. A persistent two-way connection over WebSockets, served by Node.js, carries the live broadcast: the moment a status changes on one tablet, the server pushes that change out to every other tablet at once. No one refreshes a page and nothing reloads; each screen stays current on its own. Everything else, the data storage and the reporting, stays on the existing stack, written through standard AJAX posts.

That split kept the persistence and the reporting on the platform the team already ran and maintained, while Node carried only the real-time layer. The interface itself is a web application running on the tablets, so a single codebase reaches every device over the network with nothing to install. The architecture isolates the one genuinely new capability instead of rebuilding the whole system around it.

03 — ROLE & LEADERSHIP

This came early in my career, and I led the build with mentorship from senior engineers along the way. I drove the architecture and built the web app the tablets ran on, from the client-side JavaScript to the Node server operations behind the real-time layer, which was new ground for all of us. I coordinated closely with an experienced backend developer who handled the data store and the AJAX persistence on our existing platform.

Before we committed to the full build, I stood up a small WebSocket prototype to test the one assumption everything depended on: whether our internal network could reliably hold persistent connections. Prototype, validate the riskiest assumption, then build. That sequence became a model for how the team approaches an unproven stack.

04 — TRADEOFFS

A persistent connection is not free. Unlike a page that simply reloads, a live connection has to manage reconnection and heartbeat behavior to stay reliable when the network blips. We took on that operational surface deliberately, because nothing short of a live connection could keep every tablet in sync the instant a status changed.

The simpler alternative, polling the server on a timer, would have been easier to operate but would have traded away the immediacy the whole system existed to provide. We accepted the added complexity of the real-time layer in exchange for state that is actually live.

05 — IMPACT

The system replaced the radio calls and the paper the floor team had relied on. What previously depended on whether someone heard the right radio call at the right moment now reached every tablet instantly. Status and reporting generate directly from the data store, where the attendance data lives, instead of being reconstructed from paper after the fact. The radio channels were freed for the operational communication they were meant for during Floor Sessions, rather than being tied up relaying status updates for someone to write down by hand.

A web application running live on tablets, fed by persistent real-time connections, was a new direction at the State Capitol at the time, and it proved its worth to stakeholders immediately. From the first Floor Session it ran, the floor team worked from one live picture instead of a paper record that was always a step behind. The system served reliably for nearly a decade of Floor Sessions.

It was also the first time our team had taken either Node.js or WebSockets into production. The approach that delivered it, prototype the riskiest assumption, prove it, then build, became the template the team uses to bring emerging technology into production without betting the whole system on it.