Tooshlights

Problem

Tooshlights puts a smart latch and an indicator light on a restroom stall: green when it is free, red when it is occupied, blue for ambulatory stalls. The idea reads as simple, and from a traveller's side of the door it is — you see where to go instead of guessing down a row of doors.

The engineering is on the other side of that latch. Every stall is a sensor reporting for as long as the building is open, which in an airport means continuously. The traffic is not steady: it arrives in waves timed to arriving flights, so the system faces long quiet stretches punctuated by bursts. And the value of the data depends entirely on it being current — occupancy that is thirty seconds stale is not occupancy, it is history. Beyond the lights, operators wanted the stream turned into something they could act on: which stalls get used hardest, how long a typical visit runs, and when someone has been in a stall long enough to warrant a welfare check.

Approach

Realm 8 built the server side: the database, the API, the edge functions handling the 24-hour data stream, and the dashboard on top of it.

Device traffic enters through Route 53 and API Gateway, then lands in SQS rather than hitting the database directly. That queue is the load-bearing decision. Hardware in the field reports in bursts, and a queue lets the system absorb a spike and drain it at its own pace instead of dropping events or paying year-round for a peak that happens twice a day. Lambda workers consume the queue and write to Aurora PostgreSQL Serverless, which is the system of record.

A second, separate path handles ingest from a partner data server — its own Route 53 entry, API Gateway and Lambda, writing to the same database. Keeping it independent means a partner integration problem cannot degrade device traffic.

On top of that stream sits the dashboard, built in Vue against a Node.js service layer: live stall-by-stall occupancy, usage trends over time, and alerts that fire when a stall has been occupied past a threshold. That last one is the reason the latency budget matters — an alert about a possible medical situation is only useful while it is still happening.

The same infrastructure carried the deployments at Los Angeles International, Dallas Fort Worth, Boston Logan, LaGuardia, Hartsfield-Jackson Atlanta and Seattle-Tacoma.

The whole system is serverless, so it costs nothing between events and needs no capacity planning ahead of a busy day.

Outcome

Tooshlights is deployed and in use at many of the busiest airports and facilities in the United States — among them Hartsfield-Jackson Atlanta (ATL), Dallas Fort Worth (DFW), Los Angeles (LAX) and Seattle-Tacoma (SEA) — along with stadiums and Buc-ee's stations around the country.

Where it runs, it has improved wait times for passengers and streamlined restroom maintenance for the facilities operating it.

That is the part worth sitting with, from an infrastructure point of view. The system has spent years absorbing a continuous stream from venues that do not close, across sites with nothing in common operationally beyond the shape of the problem. The serverless design was chosen so it would cost nothing between rushes and need no capacity planning before a busy day; running at that spread, across airports and stadiums and roadside stops, is the evidence that it held.