At the edge, the number that matters is memory - not throughput (specially in Ramageddon)

The headline of the article emphasizes that memory usage, rather than throughput, is the key metric when evaluating stream processing engines in resource-constrained environments like industrial gateways and embedded devices. In such scenarios, the engine must keep memory usage bounded even when traffic grows, as opposed to focusing solely on peak throughput.

To test this hypothesis, the author built a benchmark using LF Edge eKuiper and compared it to other stream processors like Telegraf and Redpanda Connect. The benchmark ran eKuiper against these engines on five real MQTT workloads, measuring message-by-message output to ensure correctness.

The most important result of the benchmark was not the speed, but the memory usage of each engine. The author found that rekuiper, the Rust-based engine they built, maintained memory usage between 5 and 10 MB across all workloads, while the Go-based engines consumed half a gigabyte to a full gigabyte, or failed altogether. This significant difference in memory usage is not due to the language choice, but rather the engine's design.

Rekuiper's memory efficiency comes from three design choices: bounded queues with real backpressure, incremental window aggregation, and an offline sink cache that spills instead of dropping records. Bounded queues ensure that messages are either delivered to all subscribers or rejected, preventing half-delivered data. Incremental window aggregation keeps memory usage proportional to the number of devices rather than the number of messages, making it safe for constrained devices.

The offline sink cache handles intermittent uplinks by queuing records in memory and disk until the disk budget is exhausted, ensuring no data is silently lost. These design decisions demonstrate that memory management is a crucial aspect of stream processing engines, even in environments where throughput is not the primary concern.