Caching / in-memory

Read with GET. Hit: return the cached value. Miss (nil): load from the system of record, serialize it, write it back with a single SET key value EX <ttl>, and return it. Readers fill the cache lazily; a miss is normal, not an error.

Deleting is the safest default: the next reader reloads from the database. Overwriting with a fresh TTL restarts the clock, so a hot key's expiry never fires and a wrong value can live forever. Overwriting while keeping the remaining TTL keeps a hard age bound.

Redis Cluster computes CRC16 of the key modulo 16384, giving a hash slot. Each of the 16384 slots is owned by exactly one master node, so the slot decides the node. Keys are never hashed against node addresses.

OBJECT ENCODING reports the internal memory layout Redis chose for that value. Small collections use a compact, cache-friendly flat array (listpack/intset) that saves a lot of memory; once they grow past configured thresholds Redis switches to a real hash table or skiplist for O(1)/O(log n) access.

HSET user:42 name Ada email [email protected] writes fields; HGET reads one, HMGET reads several in one call, HGETALL returns every field and value. HDEL removes fields, and when the last field goes the key itself is deleted — Redis has no empty hashes.

The proxy gives clients one stable endpoint: it routes to the right shard, so clients need no slot map or redirect handling, and resharding, failover and scaling happen behind it. The cost is an extra network hop, another component to size and make highly available, plus licensing and a more opaque topology.

Each region holds a full replica built on conflict-free replicated data types. Writes are applied locally, then replicated asynchronously and merged by per-type rules: counters sum, sets and hashes are add-wins, plain string values resolve last-write-wins. You do not get global linearizability, cross-region atomicity, or loss-free failover.

Keys, indexes and hot values stay in RAM while cold values live on local NVMe SSD, fetched on access. It assumes a strongly skewed access pattern, since a miss costs an SSD read instead of a memory read. It is a cost-per-gigabyte optimisation, not persistence — durability still comes from snapshots and replication.

Three gaps are structural, not packaging. Multi-master writes need merge rules built into every data type. RAM/flash tiering needs a storage engine under the shard with a promotion policy. Invisible resharding needs a routing layer owning the client connection. Single-region caching needs none of them.

The client is given the list of Sentinel addresses plus the master's logical name. It asks a Sentinel with SENTINEL get-master-addr-by-name, connects there, and subscribes to the +switch-master event so it drops connections and re-resolves after a failover. A hardcoded master IP keeps pointing at the dead or demoted node.

Sentinel is a separate Redis process that watches a master and its replicas. It detects when the master is down, promotes a replica automatically, reconfigures the other replicas, and tells clients the current master address. Data never flows through it.

A Sentinel marks the master SDOWN (subjectively down) after it fails to reply for down-after-milliseconds. It asks the other Sentinels; when quorum agree it becomes ODOWN (objectively down). Sentinels then elect a leader by majority, which picks the best replica, sends REPLICAOF NO ONE, and repoints the others.

Run an odd number, at least three, on hosts that fail independently. Quorum is how many Sentinels must agree the master is down to declare ODOWN. Performing the failover additionally requires a leader elected by a majority of all Sentinels (N/2+1). Quorum can lower but never bypass that majority.

Sentinel never tells the isolated master anything, so it keeps accepting and acking writes from clients that still reach it. Only client re-resolution ends that window, not a server timeout. On rejoin it full-resyncs and those writes are discarded silently.

Connection setup, paid before any work begins: at least one network round trip for the handshake, plus further trips where an encrypted transport or a credential exchange is required. Microseconds of server work end up buried under milliseconds of setup.

Almost all of it went into the network. Each read pays one full crossing, so 500 sequential reads pay 500 crossings. The store's microseconds are far too small to explain the delay; the number of crossings is the cost.

It promises only that no other caller's operation is applied between the four. It is not a database transaction: there is no rollback, so when the third step fails, the first two stay applied.

The second write lands whole and the first caller's addition is gone. An entry that held 100 holds 110, not 120 — and nothing is reported: both callers were told their write succeeded. That default outcome is last-writer-wins.

Another caller changed that entry between the read and the write, so the store refused it instead of overwriting. The caller must re-read the entry, recompute the change from the new value, and write with the new token.