Some Redis capabilities are absent from the open-source distribution because of how the system is constructed, not because of how it is packaged — for example accepting writes to the same dataset in more than one region simultaneously, serving cold values from flash instead of RAM, and moving shards between nodes without the connected client observing it. For each of those three, what would you actually have to build to provide it yourself on top of open-source Redis, and which workloads genuinely need none of them?

## "Absent by construction" vs "absent by packaging" Most feature lists mix two very different kinds of gap. A **packaging gap** is something that exists as a wrapper around Redis: provisioning, backups, patching, dashboards, alerting, a support phone number, one-click replica creation. You can build every one of these against unmodified open-source Redis, and every cloud provider already sells a version of them. Nothing about Redis's internals stands in your way. A **construction gap** is something that requires changing the code *below* the level a client library, sidecar, or operator can reach. You cannot add it by configuration or by putting a process next to Redis; you would have to fork it. Three capabilities fall in this category, and knowing why each one is hard is the whole point of the question. ## Gap 1 — writes accepted in more than one place at once Ordinary Redis replication is single-master: one node accepts writes, replicas apply the stream. If two regions both accept writes to the same key, you need a rule for combining concurrent, independent changes — and the rule cannot be generic, because it depends on what the value *means*. Consider a set. Region A runs `SADD members alice`; concurrently region B runs `SREM members alice`. Neither happened "after" the other in any meaningful sense. A generic external merger sees two opaque commands and can only pick a winner by timestamp — last-writer-wins — which silently discards one user's intent. A correct answer needs per-type semantics: an add-wins or remove-wins rule for sets, a per-replica counter decomposition for integers so two concurrent `INCRBY 1` operations sum to 2 rather than collapsing to 1, and something defensible for strings, hashes, sorted sets and streams. Those rules require extra metadata stored *alongside every value* — vector clocks, per-replica sub-counters, tombstones with garbage-collection rules. That metadata has to be written by the same code that executes the command, which is why this is a change inside the data structures rather than a layer around them. Building it yourself means forking Redis and reimplementing conflict-free replicated types for every type you use, plus the tombstone GC, plus the replication protocol that carries the metadata. It is a multi-year project, not a config file. (The behaviour and caveats of ready-made active-active replication are covered by the dedicated question on it.) ## Gap 2 — a storage tier beneath RAM Redis holds values in the process heap. Keeping hot values in RAM and cold values on local flash means introducing a storage engine under the shard: an on-disk representation for values, an index from key to location, a **promotion policy** that decides when a flash-resident value must be pulled back into memory, and an eviction/demotion policy going the other way. The naive substitute — give the machine a big swap file and let the OS page — fails for a specific reason: Redis executes commands on a single thread, so a page fault taken while serving `GET` stalls every other client on that shard until the disk returns. The OS also pages at 4 KB granularity with no knowledge of key boundaries, so a hot key can sit on a cold page. A real tiering implementation performs the fetch off the command thread and keeps hot metadata (keys, expiries, and typically small values) resident so that the common path never touches disk. Building this yourself is a storage-engine project layered into a database that was designed on the assumption that memory access is free — and every latency guarantee Redis makes has to be re-derived once that assumption is gone. Its economics also depend entirely on access skew: without a small hot set, you get disk latency at RAM prices. ## Gap 3 — moving shards without the client noticing Open-source Redis Cluster *can* migrate slots while online, but it does so by making the client complicit: the client must understand the slot map, follow `MOVED` and `ASK` redirects, and refresh its topology. Every language's client implements that with its own bugs, and connections churn during a reshard. "Invisible" resharding means the client holds one stable endpoint and knows nothing about slots. That requires a routing layer that terminates the client connection and re-targets requests as topology changes — which means it now owns connection state, pipelining semantics, MULTI/EXEC affinity, blocking commands, and pub/sub subscriptions. Building it is a real distributed-systems component sitting on the hot path, and it introduces a hop that must be made highly available itself. (The proxy-versus-smart-client tradeoff is covered by the dedicated question on it.) ## The honest converse None of this is needed by most workloads. A single-region cache, a session or rate-limit store, a queue, a leaderboard — served entirely by open-source Redis. A standard primary/replica pair or a Cluster deployment, with automated failover through Sentinel or Cluster's own election, covers ordinary high availability; "we want automatic failover" is not a capability gap. Backups, TLS, ACLs, metrics and rolling upgrades are all present. If you cannot write down a requirement that specifically needs multi-region write acceptance, sub-RAM cost per gigabyte at verified skew, or client-invisible topology change, the structural gaps do not apply to you. ## How to answer this in an interview Name the three gaps, explain in one sentence each *where* the missing machinery would have to live (inside the data types, beneath the shard, in front of the connection), give the concrete failure of the obvious shortcut (last-writer-wins loses operations; swap stalls the event loop; redirects leak into every client), and then state plainly which workloads need none of it. The signal being tested is whether you can tell an architectural limitation from a pricing tier.