When a gateway loses its link to the cloud, it has to keep the readings it is collecting somewhere until the link returns. That local store cannot be infinite; the device has a finite amount of memory or flash. A ring buffer is the data structure most often used to hold that backlog: a fixed-size circular store that, when full, begins overwriting its oldest entries. This guide explains what a ring buffer is, how it behaves as it fills and wraps around, and what design choices govern the moment it overflows, which is where store-and-forward has to decide what data it is willing to lose.
Edge Historian Ring Buffer in one line: An edge historian ring buffer is a fixed-size circular store on a gateway that holds timestamped samples which have not yet been forwarded to the cloud, typically during a communication outage. Because its size is bounded, when it fills up it either overwrites its oldest entries or applies backpressure, and that overflow policy determines whether the newest or the oldest data survives a long interruption.
A ring buffer, also called a circular buffer, is a block of memory of fixed capacity that is treated as if its end were joined to its beginning. Two positions move through it: a write position where new samples are added and a read position from which forwarded samples are removed. As the gateway collects readings it advances the write position, and as it successfully sends readings upstream it advances the read position. Both wrap around from the end of the block back to the start, so the buffer never needs to shuffle data, and it uses a constant, predictable amount of memory no matter how long it runs.
During normal operation with a healthy link, the buffer stays nearly empty, because samples are forwarded almost as fast as they are collected and the read position chases the write position closely. The buffer earns its keep during an outage. When the link drops, forwarding stops, the read position stalls, and the write position keeps advancing as new readings arrive. The gap between them grows, representing the backlog of unsent data, and the buffer gradually fills toward its fixed capacity.
The appeal of a ring buffer for this job is that it is bounded and cheap by design. A gateway with limited memory cannot let a backlog grow without limit, and a ring buffer enforces that limit structurally: it can only ever hold as many samples as it has slots. It avoids the fragmentation and unbounded growth of a store that keeps allocating, and its constant memory footprint makes the device's behaviour predictable, which matters on small embedded hardware that must never run out of memory in the field.
The interesting behaviour begins when an outage lasts long enough that the write position catches up to the read position and the buffer is full. At that point the gateway faces an unavoidable choice, because it has more data than it can hold and the link is still down. There are two broad answers, and which one a system uses is a deliberate policy decision with real consequences for what survives a long interruption.
The most common ring-buffer behaviour is to overwrite the oldest data. When the buffer is full and a new sample arrives, the write position advances over the oldest unsent entry, discarding it to make room. This keeps the most recent readings and sacrifices the earliest part of the backlog, which is often the right trade for monitoring, since a very old sample from early in a long outage is usually less valuable than a fresh one. The cost is a hole in the history: the beginning of the outage window is lost, and when the link returns the record jumps from before the outage to partway through it.
The alternative is to stop overwriting and instead apply backpressure, refusing new samples or telling the acquisition side to slow down rather than discarding old ones. This preserves the earliest data and instead drops or thins the newest, which can be the right choice when the start of an event matters more than its continuation, or when losing the oldest data would break a required record. The two policies are opposites in what they protect, and the correct one depends entirely on whether the freshest or the earliest data is more valuable to the operation.
The ring buffer is the concrete mechanism behind store-and-forward on a resource-constrained gateway. Store-and-forward describes the behaviour of holding data locally during an outage and sending it when the link returns; the ring buffer is one way to actually implement the store. Its fixed size directly determines how long an outage the site can ride out without loss: a buffer sized for an hour of samples protects an hour of downtime, and an outage longer than that begins to overwrite or reject data according to the overflow policy.
Sizing the buffer is therefore a capacity-planning decision informed by the sampling rate and the expected worst-case outage. A site that samples many fast tags fills a buffer of a given size much sooner than one reporting a few slow tags, so the same memory buys very different amounts of outage tolerance depending on the workload. Some designs make the overflow policy configurable per tag or per priority, so that critical measurements keep overwriting the oldest data while less important tags are dropped first, blending the two policies to protect what matters most.
For a cloud SCADA platform such as Merobix that reconciles data after outages, understanding a site's ring buffer explains exactly what to expect when a link is restored. The backlog arrives as a burst of timestamped historical samples to be merged into the record, and the buffer's size and overflow policy tell you whether that record will be complete or whether the oldest part of a long outage was overwritten. Knowing the buffer's limits lets an operation set realistic expectations for data completeness and size local storage so that ordinary outages are covered without loss.
When a ring buffer is full and a new sample arrives, one of two things happens depending on the configured overflow policy. The common behaviour is to overwrite the oldest unsent entry, keeping the newest data and losing the earliest part of the backlog. The alternative is to apply backpressure and refuse new samples, preserving the oldest data instead. Which is correct depends on whether the freshest or the earliest readings matter more.
Size it to cover the longest outage you want to survive without losing data, based on your sampling rate. A buffer holding an hour of samples protects roughly an hour of downtime, and a site sampling many fast tags fills a given buffer far sooner than one with a few slow tags. Because memory on a gateway is finite, sizing is a trade-off between outage tolerance and the resources the device has available.
Store-and-forward is the overall behaviour of holding data locally during an outage and sending it once the link returns. A ring buffer is a specific fixed-size, circular data structure often used to implement the local store within that behaviour. In other words, store-and-forward is the strategy and the ring buffer is one common mechanism, notable because its bounded size forces an explicit decision about what to discard when it overflows.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.