The edge is not a smaller server

The first version of our edge runtime was the server runtime with features removed. It worked in the lab and fell over in the field, because the field has properties the lab does not: the link drops, the power cycles, and nobody is on site to restart anything.

Buffering is the architecture, not a feature

On a server, a failed write to the historian is an error you log and retry. At the edge, a failed write is normal. The link is down for six hours a week in a lot of real deployments, and every one of those hours must produce data that survives.

That inverts the design. The edge does not write to the historian and buffer on failure — it always writes to a local durable queue, and a separate process drains that queue when a link exists. There is no fast path and slow path, because a fast path is a fast path to divergent behaviour under exactly the conditions you cannot test.

Sizing the buffer is a business decision

"How long should the edge buffer?" is not an engineering question. It is: how long can this site be offline before losing data costs more than the storage would?

For a regulated pharma line, the answer is "longer than any plausible outage" and you fit a 32 GB card. For a temperature logger on a warehouse, three days is generous. We expose it as a duration, not a byte count, because operators can reason about days and cannot reason about bytes per sample per tag.

Reconciliation is where the bugs live

When the link returns, the edge has hours of backlog and the server has a live present. Naively replaying the backlog means the server sees six-hour-old timestamps arriving after fresh ones.

Everything downstream must therefore be timestamp-ordered rather than arrival-ordered — the historian, aggregations, and alarm evaluation. Alarm evaluation on replayed data is its own decision: replaying a six-hour-old high-temperature alarm and paging someone at 2 a.m. about a condition that cleared before dinner is not helpful. We evaluate alarms at the edge, at the time they occur, and replay the outcome rather than re-deriving it.

We got that wrong in an early build. Exactly once. It is not a mistake you repeat.

No inbound ports, ever

OT networks do not accept inbound connections, and asking for a firewall exception is how a six-week project becomes a six-month one. The edge dials out, holds the connection, and receives configuration over it.

This also makes the security story simple enough to fit in one sentence, which matters more than it should when the person reviewing it is not an OT specialist.

What 512 MB actually forces

Running in 512 MB is not achieved by trimming. It is achieved by not having a garbage collector under pressure, streaming rather than materialising, and a hard cap on per-connection buffers so one misbehaving PLC cannot starve the rest.

The useful side effect: everything we did to fit the edge into 512 MB made the server cheaper to run too. Constraints are a good editor.