How it runs

One process. The shard that owns the key does the work.

Ruvio speaks RESP so the clients you already have can connect. The shard that owns the slot parses, records, applies, and replies. LEASE, SEMAPHORE, INCRBY MAX, SETV, CHANGES, and XADD DELAY stay on that shard.

One owner per shard

The hot path does not take a shard mutex. The core that owns the slot does the work.

Validate, record, apply

A WAL or sink failure leaves the key unchanged. The contract is written in docs/adr/0002-durability-contract.md. Detail is on Durability.

Named durability

memory, snapshot, everysec, always — each with an acknowledgement boundary. You do not infer durability from a generic “persistence on” flag.

Static slots

16,384 slots, hash tags, MOVED, CROSSSLOT, CLUSTER SLOTS/NODES/SHARDS/KEYSLOT. No gossip bus, no migration, no election. The map is static and local.

First-party clients

One seed address. Ruvio.Client and ruvio-client learn the slot map, open one socket per shard, split MGET/MSET/DEL, and follow MOVED. You do not configure shard ports in the app. Detail is on Clients.

How a Ruvio process runs

Install from Packages and open a client from Clients.

Common questions

Short answers for developers new to in-memory data stores. Timings depend on the configured durability profile and the shard's workload.

When does a key expire?

Its TTL is an absolute deadline on the owning shard's clock. Reads treat it as missing once the deadline passes; a bounded background sweep also removes expired keys, so physical cleanup may happen later.

When are indexes and expired hash fields cleaned up?

Deleting or expiring a key removes its deadline and access metadata with it. Expired hash fields are removed when accessed or by a bounded periodic sweep; there is no promise that every expired field is physically gone at the exact deadline.

When does a write reach the WAL?

In everysec or always mode, a successful mutation is recorded before it changes memory and before the reply; always also syncs before replying, while everysec syncs periodically. memory writes no WAL, and snapshot relies on checkpoints instead. Compare durability profiles.

When is a checkpoint created?

SAVE and BGSAVE create one on request; the optional interval and minimum-mutation threshold can also schedule one. Once published, a checkpoint lets Ruvio remove WAL segments it covers; BGSAVE is in-process and is not a forked background worker.

What happens after a restart?

With persistence enabled, Ruvio loads the latest valid checkpoint and replays subsequent WAL records when the profile uses a WAL. In memory mode data is not recovered; a retained CLOCK floor prevents a backward wall-clock adjustment from making local deadlines younger.

Does a replica make writes instantly safe?

No. Replicas receive the primary's WAL asynchronously, so a newly acknowledged write may not have reached one yet. Host clock skew can also change when each node considers a TTL expired; promotion needs an explicit recovery plan. Read the replication limits.

Is LEASE a distributed lock?

It coordinates holders of one key on one serving shard, but expiry cannot stop an old holder from writing to another system. Tokens continue while the key is retained but can restart after deletion or data loss; external writes need their own fencing or version checks.

When does a rate-limit window reset?

LIMIT starts a fixed window on its first accepted call and gives that key a deadline. Rejected calls do not extend it; after the deadline the next accepted call starts a new window on the serving shard's clock.

What happens when memory fills up?

Without a configured memory budget there is no automatic limit. With one, noeviction rejects writes that exceed it; sampled eviction policies may instead remove eligible keys. See memory options.