Persistence and distribution
Calling this an in-memory engine describes its speed, not its durability or its scope. It has both, and they are the reason it is a platform component rather than a cache.
Persistence
| Mechanism | What it does |
|---|---|
| A filesystem write-ahead log | Writes land in a durable log, so a restart replays rather than losing the keyspace |
| WAL attestation | The log is attested, so its integrity is checkable rather than assumed |
| Snapshots | Point-in-time state, for recovery and for moving a structure between cells |
| Tiered spill | Cold keys move out of RAM to durable tiers rather than being lost |
The write-ahead log is the primary durability story and it is the engine's own, not borrowed. Structures does not persist through the SQL database; it has its own log, its own snapshot format and its own recovery path.
Spilling beyond RAM
This is the property that most separates it from a cache, and it has a specific consequence worth stating.
Cold keys spill through three tiers:
| Tier | Where | Restored |
|---|---|---|
| Hot | In-process, memory speed | Already there |
| Warm | Local durable storage | Transparently on access |
| Cold | Object storage | Promoted back to warm on a hit |
Victim selection is least-frequently-used, then least-recently-used, so what leaves memory is what the workload actually stopped caring about. The mechanism is codec-agnostic: the caller serializes an entry using the engine's own snapshot codec, and the tier backends move bytes.
The consequence: a structure can exceed a cell's RAM. Combined with placement across cells, a single logical structure can exceed even the pooled RAM of the whole cluster. That is not a thing a cache can do, and it is the difference between a data structure you size to memory and one you size to your data.
Distribution across cells
Placement follows the Redis Cluster model: CRC16 hashing over 16,384 slots,
with {hashtag} co-location so related keys land together, and MOVED and
CROSSSLOT responses so a standard cluster-aware client follows a redirect
without special handling.
What decides slot ownership is the platform's own topology rather than a flat hash: slots are placed by CRUSH placement with failure-domain spread, the same machinery that places storage shards, with a single-cell fast path so a one-cell deployment pays nothing for the distribution model.
Replica policy is per structure type
A uniform replica count across every structure type is a waste in one direction and a risk in the other, so the distribution table declares a replica count and an affinity per type:
- Probabilistic sketches declare zero replicas. A Bloom filter, a HyperLogLog or a t-digest is an approximation that can be rebuilt, and spending high availability on one is spending it in the wrong place.
- Graph, vector and geospatial types declare same-zone affinity, because those are latency-sensitive and placement should keep them close.
A resolver applies the per-type policy, clamped to what the topology can actually satisfy.
Convergence
Cross-cell writes converge through the conflict-free replicated data types in the type surface: a counter, a register, a flag, a set and a map, with last-writer-wins, positive-negative counter and observed-remove semantics.
Around them: a replicator, resync with records, reconcile, a consistency resolver, flow control, and resharding when the slot map changes.
The reason CRDTs matter here specifically is the disconnected case. A device or a partitioned cell can keep accepting writes and converge deterministically when it rejoins, with no central arbiter to be unreachable.
Protection during failover
A distributed store's real test is what it does when a primary is isolated but still running.
Structures reuses the platform's epoch fence. When a cell is promoted to own a partition it acquires the fence, which monotonically bumps the epoch, so any token held by a now-isolated old primary becomes stale. A write validates its token or epoch before serving, so a partitioned old primary cannot serve stale writes.
That is an explicit rejection layer on top of the strong-consistency quorum, which already prevents a partitioned primary's writes from reaching durable acknowledgement. Two independent mechanisms, because split-brain is the failure mode where one is not enough.
Partitions are keyed by structure namespace, so the fence is scoped to the thing that actually failed over.
What else the distribution layer carries
| Capability | What it is for |
|---|---|
| Transactions | Across the distributed keyspace |
| Snapshots | For recovery and relocation |
| Materialized views and aggregation | Derived structures maintained across cells |
| Scope and scope authorization | Which workspace a structure belongs to, and who may reach it |
| Metering | Per-command consumption, attributed |
| Service-level objectives | Declared targets for the distributed keyspace |
| Ontology binding | Structures bound to the customer's object model |
Related
- Structures, the type surface and the engine.
- Concurrency and expiry, locking, snapshot isolation and TTL.
- The wire, the Redis-compatible surface and its cluster semantics.
- Object storage, the cold tier underneath spill.
- Scale-out and elasticity, the sibling engine's distribution plane.