# 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](/docs/pipeline_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](/docs/pipeline_status_indicators).