Warehouse Telemetry Gateway

The client's warehouses ran a few thousand handheld scanners plus door and temperature sensors, and when a site reported problems nobody could tell whether it was the devices, the local network or the application. Site managers would call, someone would drive out, and often the answer was a wifi access point. There was no history either, so recurring faults looked like new ones every time. They wanted a place where device and sensor health lived, with enough retention to see patterns across weeks.

I came in as the backend engineer on a two-person team — me and an engineer who knew the device firmware side. This was a smaller engagement than most of my work, about four months, and I liked it for that. I owned everything from the network edge inward and had a fairly free hand on the design, which is rarer than it sounds.

I built the gateway that terminates MQTT from the sites, validates and normalises messages, and writes them into a time-series store. I owned the retention and downsampling policy, the alerting rules, and the dashboards the site managers actually use. I wrote the buffering behaviour for site outages — devices queue locally and the gateway accepts backdated messages without corrupting the aggregates, which was the fiddliest part. I didn't work on the device firmware or the local network at all; that was my colleague and the client's IT team.

I chose TimescaleDB over a dedicated time-series database mainly because the client's small IT team already ran Postgres and would be operating this after we left. A purpose-built store would have handled the volume more gracefully, but a system nobody can operate is worse than one that's slightly overworked. I also decided the gateway would never reject a malformed message outright — it writes it to a raw table with the parse error attached, because we discovered early that firmware versions in the field disagreed with the specification and silently dropping those would have hidden the problem. Alerting is deliberately per-site rather than per-device, since a single scanner dying isn't news and forty of them is.

Site connectivity is genuinely poor at two of the locations, with outages of several hours, so anything that assumed a live connection was off the table. The devices are a mix of three hardware generations with firmware we couldn't update quickly, so the gateway had to tolerate all three. We also had a hard cap on cloud spend that ruled out retaining raw messages for more than a fortnight, hence the downsampling.

Site visits for connectivity issues dropped noticeably in the first quarter — the client's number was around a two-thirds reduction, though I'd treat that as approximate since we changed several things at once. The clearer result is that a recurring afternoon dropout at one site turned out to be a freezer compressor on the same circuit, which the history made obvious and which had been misdiagnosed as a software fault for over a year. The client's IT team has since added two sensor types themselves.

The firmware engineer I worked with understood the field conditions in a way I didn't and repeatedly stopped me designing for a network that didn't exist. The client's IT lead ran the rollout site by site and wrote the runbook. Two site managers reviewed the dashboards early and cut about half of what I'd put on them, correctly.