Skip to main content

​
When is a write durable?

An append is acknowledged after a majority of nodes have replicated it. A single node failure cannot lose an acknowledged write. No write is ever acknowledged based on a single copy. Acknowledged data is held in replicated hot state across the cluster. A background process then flushes data to S3 on a configurable interval, after which the data inherits S3-grade durability. In a cross-region deployment with a 5-second flush interval, Snakream provides approximately 9-10 nines of per-message durability. The window where acknowledged-but-unflushed data is at risk from a simultaneous multi-region failure is measured in seconds.

​
Consistency model

Snakream provides linearizable writes. All appends are serialized through a single leader node, which assigns a total order. Reads on the leader are linearizable: if an append has been acknowledged, any subsequent read on the leader will reflect that write. Follower reads are eventually consistent and may lag slightly behind the leader (typically sub-millisecond). They will never see data out of order or observe a write that was later rolled back, but a follower may not yet have applied the most recent committed writes. The Stream-Up-To-Date response header indicates whether the serving node has fully caught up.

​
Data lifecycle

Writes first enter replicated hot state across cluster nodes. This is where acknowledgment happens and where recent reads are served from. A background process flushes older data to S3 on a configurable interval. Once flushed, the data gains S3-grade durability and nodes can recover it without replaying the full history. Reads fall through transparently from hot to cold storage.

​
Availability and durability

The estimates below assume a standard Snakream deployment: three voting replicas across availability zones, with two non-voting replicas in a second region.