The network will drop, plan for it

The first time I demoed the race-timing system on real hardware, the venue Wi-Fi dropped for eleven seconds while a runner crossed the finish line. In a spreadsheet that is an annoyance. In race timing it is a missing result, an angry runner, and a dispute you cannot resolve because the read simply never arrived.

You cannot fix the venue's network. You can stop trusting it.

Move the reader connection off the cloud

The readers speak a binary TCP protocol, and my first instinct was to have them talk straight to the backend. That couples every tag read to the internet being up. Instead I put a small Electron app, the Reader Console, on the timing laptop at the start line. It holds the persistent socket to the readers and owns the reads the moment they happen. Local hardware talking to local software over the LAN, which is the one link at a venue I can actually rely on.

Buffer to disk, not to memory

The Console forwards reads to the backend over HTTP, but every read is written to an on-disk queue first. If the POST succeeds, the row is marked sent. If it fails, it stays. An in-memory queue would have lost everything the moment someone closed the lid or the process crashed, so the queue is a real file that survives a restart.

async function flush() {
  const pending = queue.take(50); // oldest first, off disk
  for (const read of pending) {
    try {
      await post("/api/reads", read);
      queue.markSent(read.id);
    } catch {
      break; // network's down, stop and keep the rest for the next tick
    }
  }
}

A retry loop drains the queue whenever the network comes back. Reads go out oldest-first so splits stay in order, and because the backend dedupes on tag plus timestamp, a read that gets sent twice after a flaky reconnect is harmless.

What the operator sees

Nothing, which is the point. During that eleven-second outage the Console kept reading, the queue grew by a few rows, and when the Wi-Fi came back it drained in under a second. The finish-line result was correct and on time. The operator never knew there was a gap.

The lesson stuck with me for everything since. If a system touches the physical world, the failure mode is not "if the network drops" but "when," and the design either has an answer or it loses data. Buffer locally, dedupe on the far end, and make the recovery boring.