Consistency levels
Silos offers four tunable, per-query consistency levels — eventual, read-your-writes (default), bounded-staleness, and strong.
Replication trades freshness for locality. Silos makes that trade-off your choice, per query, with four consistency levels. The default is read-your-writes (session consistency), so the common case "I want to see my own writes" works without any configuration.
The four levels
Eventual
Read from any replica. Fastest, may be stale. Good for data where slight lag is fine — feeds, dashboards, analytics.
Read-your-writes (default)
Within a session, you always see your own writes. Reads from other sessions may still be slightly behind.
Bounded staleness
Read data no older than a bound you set (e.g. N seconds). A middle ground between eventual and strong.
Strong
Always read from the primary. Freshest possible, at the cost of the round-trip to the primary's region.
Eventual
The read goes to any available replica and returns whatever that replica currently has. It may lag the primary. This is the cheapest and lowest-latency option — choose it when slight staleness is acceptable.
Read-your-writes (session) — the default
Within a session, any read is guaranteed to reflect that session's own prior writes. This is implemented with LSN tokens: a write returns a log position, and a subsequent read requires the replica to have caught up to at least that position (or is routed to the primary). See Read-your-writes.
Bounded staleness
The read may use a replica, but only if its data is no older than a staleness bound you specify. If the nearest replica is too far behind, the request waits for it to catch up or routes to a fresher source. Use this when "a few seconds old is fine, but not minutes."
Strong
The read is served by the primary, so it always reflects the latest committed state. This is the strongest guarantee and gives up the local-read latency benefit for clients far from the primary.
Choosing a level
| Your need | Level |
|---|---|
| Lowest latency, staleness OK | Eventual |
| See my own writes (most apps) | Read-your-writes (default) |
| Tolerate bounded lag, not unbounded | Bounded staleness |
| Always the freshest data | Strong |
The CLI and SDKs commonly surface three of these by name — eventual,
read-your-writes, and strong — with read-your-writes as the default.
Bounded-staleness is also part of the model. Pick the weakest level that still
satisfies your correctness needs; it'll generally be the fastest.
Consistency levels are implemented as types and routing logic, but they ride on
the rolling-out global replication path. Until cross-region WAL streaming is
production-proven, the strongest dependable guarantee is reading from the primary
(strong). See the Replication overview.