Reliability & Delivery

How Monad keeps data flowing during traffic spikes, slow destinations, and node restarts — and what delivery guarantees you can rely on.

Overview

Monad is a managed, always-on streaming platform. Back-pressure handling, durable buffering, and failover are built in — you don't deploy or tune a separate message bus to get them. This page describes the guarantees; the Status Indicators page describes the operational states (Paused, Throttled, etc.) you'll see while they're in effect.

Absorbing bursts with back-pressure

When a destination slows down or incoming volume spikes, Monad applies back-pressure instead of dropping data. In-flight records are buffered and drain automatically once capacity returns.

• The buffer is self-limiting: as it fills, Monad throttles ingestion at the input so the buffer cannot grow without bound. Pull-based inputs pause and resume automatically; push-based inputs (HTTP, OTLP, Splunk HEC, syslog) receive a 429 Too Many Requests until capacity frees up.
• Because Monad holds buffered data until the backlog clears, no data is lost on Monad's side during a burst.
• The only loss cases are external: a pull source that ages out its own data while a pipeline stays throttled longer than that source's retention window, or a push client that does not honor 429 responses.

Durable buffering

In-flight data is held in a durable buffer that is replicated across multiple nodes, not just kept in memory on a single node. An individual node or pod restart does not lose buffered data — it remains available for processing when the pipeline resumes.

Failover and no-loss recovery

Work is distributed with durable checkpoints. If a node fails or restarts, another node resumes processing from the last acknowledged checkpoint, so acknowledged data is not lost.

Delivery is at-least-once: on recovery, records that were in flight but not yet acknowledged are re-processed rather than dropped. Design downstream consumers to tolerate the occasional duplicate (for example, by keying on a stable event identifier).

No external message bus to operate

These guarantees are native to the platform. You do not need to run or tune an external message bus (such as Kafka) in front of Monad to get durable buffering or burst absorption — the durability and back-pressure described above are part of the managed service.

What you can rely on

• Bursts are absorbed with back-pressure; Monad does not silently drop data to shed load.
• Buffered, in-flight data survives node and pod restarts.
• On node failure, processing resumes from the last acknowledged point with at-least-once delivery.
• No separate message bus is required to achieve any of the above.

For the operational states that surface these behaviors in the UI, see Status Indicators.