Distributed cache cluster

First, I never use modulo hashing; I map keys to a fixed set of slots or virtual nodes, so a new node takes only about one over N plus one of the keyspace. Then I migrate gradually: the rebalancer picks a few slots, copies their keys to the new node while the old owner still serves them, and only then flips ownership in the config with a new epoch. During the move, a request for a key that has already moved gets a redirect, so the client follows it rather than missing. I throttle migration speed, watch database QPS and hit ratio, and pause if misses rise. The net effect is that users barely notice, and the database sees a small, bounded bump instead of a cold-cache spike.

A stampede happens when a popular key expires or is evicted and many concurrent requests miss at once, all hitting the database to rebuild the same value. I use layered defences. Request coalescing, or single-flight, lets only one caller per key go to the database while the others wait for its result. A short lease or lock in the cache does the same across many app instances. I add random jitter to TTLs so keys loaded together do not expire together. For very hot keys I refresh early, either probabilistically as expiry nears or with a background refresher, and allow serving a slightly stale value while the rebuild runs. Together these keep database load roughly constant even under heavy traffic.

The app calls the smart client. The client hashes the key with CRC16 mod 16384 to get a slot and looks up the owner in its cached slot map. If the key is flagged hot, it first checks a small in-process L1 with a very short TTL, or reads from a replica. Otherwise it sends the GET to the slot's primary. A hit returns at once. A MOVED redirect makes the client refresh its slot map and retry. An ASK redirect sends a one-off retry to the importing node. On a miss, single-flight lets one caller per key load from the database, write the value with a jittered TTL, and serve the callers that were waiting. Throughout, the client records latency and the hit or miss for telemetry.

MOVED means the slot now belongs to another node permanently. The client should update its slot map, either for that slot or by refreshing the whole map with CLUSTER SHARDS, and then retry on the new owner. ASK appears only during a slot migration. It means this particular key has already moved to the importing node, but the slot itself has not been reassigned yet. The client sends ASKING followed by the command to the target node, just once, and does not change its slot map. Later requests for that slot still go to the old owner until migration ends and a MOVED shows up. If a client wrongly updates its map on ASK, it can send requests for keys that have not moved to the importing node, which will just redirect them back.

First, make the bound explicit for each data type, for example 30 seconds for a product price. Every cached value gets a TTL no longer than that bound, and jitter only shortens the TTL, never lengthens it. The L1 TTL must also fit within the bound, counting time spent on replicas, so total staleness equals L1 TTL plus replication lag plus the shared cache TTL. Next, on writes, invalidate rather than wait for expiry, and use change-data-capture from the database binlog as a backstop for missed deletes. If you serve stale values during a stampede, store the original load time with the value and refuse anything older than the bound. Finally, alert on replication lag so replica reads cannot quietly break the budget.

For detection, the client or a proxy samples requests and counts keys over a sliding window, for example with a count-min sketch, and marks keys above a threshold as hot. With an LFU policy, server-side tools such as redis-cli --hotkeys also work, but client sampling responds faster. For mitigation, hot keys are served from an in-process L1 with a TTL of a second or two, which removes most of the traffic before it reaches the network. For heavy reads you can also spread load across replicas, or split the key into N copies such as key#0 to key#7 placed on different slots, with clients picking a copy at random. Writes to a split key have to update or invalidate every copy. Hot status should be dynamic and expire on its own.

If two writers update the database and then each sets the cache, their cache writes can land in the opposite order to their database commits. The cache then holds the older value until TTL. Deleting the entry avoids that, because the next reader loads whatever is current. One race remains. A reader misses, reads the old value from the database, and pauses. Meanwhile a writer commits and deletes the key. The reader then writes the old value back. This is uncommon but real. Ways to reduce it include leases, where the server hands out a token on a miss and rejects the fill if a delete happened in between, version-checked sets, a short delayed second delete, and a TTL that caps how long the damage can last.

Other nodes stop getting heartbeats. After the node timeout they mark the primary as possibly failed, and once a majority of primaries agree, it is marked failed. Its replicas wait a short delay based on replication offset, so the most up-to-date replica usually asks first, and they request votes. A replica that wins a majority of primaries is promoted, takes a higher config epoch, and announces the new ownership. Clients get MOVED replies or refresh their maps and then follow the new primary. Because replication is asynchronous, writes the old primary acknowledged but never sent to the replica are lost. For a cache that loss is usually fine. For write-back data it is not, which is why write-back needs a durable queue outside the cache.

That is a cache avalanche. Hit ratio drops to near zero and the full read load hits the database. Prevention starts with jittered TTLs, so keys loaded together do not expire together, and with replicas and persistence so one failure does not empty the cache. For the cold-start case, warm the cache from an RDB snapshot or by replaying a list of hot keys before taking traffic, and add nodes back gradually. At the database edge, put a concurrency limiter or circuit breaker in front of loads. Requests beyond the database's safe capacity get a stale value, a default, or a fast error rather than queuing. Single-flight still applies per key. The goal is to degrade gracefully, never to overload the database.

Write-through updates the database synchronously as part of the write, so the cache and the source of truth stay aligned and an acknowledged write is durable. I pick it, or cache-aside with invalidation, for money, inventory, permissions and anything where losing or reordering a write is unacceptable. Write-back acknowledges after updating the cache and flushes to the database later in batches. It gives lower write latency and absorbs bursts, which suits counters, view stats or session activity. The cost is that a node crash can lose unflushed writes, and reads from other systems hitting the database see old data. If I use write-back, I put writes on a durable log and make the flush idempotent, so the loss window is small and replay is safe.

Split-brain happens when a network partition leaves the old primary running on the minority side while the majority side promotes a replica. For a while, two nodes believe they own the same slots. Redis Cluster limits this in two ways. A primary that cannot reach a majority stops accepting writes after the node timeout, which caps how long it can diverge. Every ownership change also carries a config epoch, and when nodes see conflicting claims, the higher epoch wins. When the partition heals, the old primary sees the higher epoch, steps down to become a replica, and throws away the writes it took during the split. Clients that reach it get redirected. The remaining risk is the writes accepted during that short window.

Missing keys always miss, so an attacker or a bug can push every one of these requests to the database. The first defence is negative caching. When the database returns nothing, cache a placeholder with a short TTL, and keep it short so a record created later shows up quickly. For large keyspaces, put a Bloom filter of valid IDs in front. A Bloom filter never gives a false negative, so a 'not present' answer can be rejected without touching the database. It does give occasional false positives, which simply go through to the database as normal. Add input validation such as ID format and range checks, plus per-client rate limits. Also alert on a rise in misses that return empty results.

Raw data is 200 million times 500 bytes, about 100 GB. Per-key overhead from the key itself, dictionary entries and allocator waste is significant for small values, so I would assume 1.5 to 2 times raw, giving about 150 to 200 GB. Add headroom for fragmentation and copy-on-write during snapshots, and aim for around 60 to 70 percent memory use. That points to roughly 300 GB of primary memory, or about 12 shards of 25 GB. For throughput, I would benchmark one node with our value sizes and pipelining rather than assume a number. If a node safely handles about 100k ops per second, 1 million needs at least 10 primaries, so 12 works with margin. One replica per primary doubles memory. I would validate this with a load test.

A fixed slot space separates key placement from node placement. The key-to-slot mapping never changes. Only slot ownership changes, and that is a small, explicit table that clients can cache and nodes can gossip. Moving load means reassigning specific slots, which is easy to reason about, migrate one at a time, and monitor. Balance is controlled directly, because you assign equal slot counts or move individual hot slots, instead of depending on where random virtual node points happen to fall. It also makes redirects simple, since a node knows exactly which slots it serves. The trade-offs are a fixed upper limit on how finely data can be split, 16384 in Redis Cluster, and the need to run something that decides slot assignment.

Commands such as MGET, MULTI/EXEC transactions or Lua scripts that touch several keys only work when all keys hash to the same slot. Otherwise the server returns a CROSSSLOT error. Hash tags solve this. If a key contains braces, only the text inside them is hashed, so user:{42}:cart and user:{42}:profile land together. The pitfall is skew. If the tag has low cardinality, such as a tenant ID with one giant tenant, a whole tenant's data sits on one slot, creating hot shards and slots too large to migrate quickly. Use tags only for small, naturally grouped data. For wider reads, let the client split the keys by slot and send the requests in parallel instead of forcing everything onto one slot.

Replicas trail the primary because replication is asynchronous, so a replica read can return a value that was just overwritten or deleted. That breaks read-your-writes. A user updates a profile, refreshes, and sees the old version. It also adds replication lag to the staleness budget. In Redis Cluster a client has to send READONLY on the replica connection to read there. I would use replica reads only for hot, read-heavy keys that tolerate a little staleness, monitor replication offset lag per replica, and have clients stop using a replica whose lag goes above the budget. For keys that need read-your-writes, route the writer's own reads to the primary for a short window after a write, or keep them on primary only.

A big key is a single value or collection that is very large, such as a multi-megabyte string or a hash with millions of fields. Command execution is effectively single-threaded per node, so reading, deleting, expiring or migrating such a key can block every other client on that shard and cause latency spikes. It also skews memory and network use and slows slot migration. To handle it, find big keys with scans such as redis-cli --bigkeys or MEMORY USAGE sampling, and set size limits in client libraries. Split large collections into buckets by sub-key hash, and paginate with HSCAN or SSCAN rather than full reads. Use UNLINK instead of DEL and enable lazy-free options so large frees happen in the background.

If the cache is the only place holding dirty writes, losing the primary loses them, because replication is asynchronous. So write-back needs the write to be durable somewhere before the client gets an acknowledgment. Usually that means appending to a replicated log such as Kafka, or a Redis Stream with AOF fsync and replicas plus WAIT, and the cache update happens alongside. A flusher consumes the log in batches and applies idempotent upserts keyed by entity and version, so replays after a crash are safe. It commits offsets only after the database confirms. Monitor consumer lag as the measure of durability debt, and apply backpressure if it grows. Reads during the delay come from the cache, which is the newest copy.

The simplest control is a very short TTL, a second or two, kept inside the staleness budget, and only for keys flagged hot. That bounds staleness without any coordination. For tighter freshness, Redis server-assisted client-side caching helps. With CLIENT TRACKING, the server remembers which keys a client has read, or which prefixes in broadcast mode, and pushes an invalidation message when they change. On reconnect or a lost invalidation channel, the client must flush its whole L1, because it cannot know what it missed. Cap L1 by entry count or memory so it cannot hurt the application's heap. Never put sensitive per-user data in a shared process cache without scoping it by user.

Local single-flight cuts it to one database load per server per key, so up to 500 loads, which may still be too many for a hot key. To coordinate across servers, use a short lock in the cache itself, SET key:lock token NX PX with a timeout of a few seconds. The winner loads and fills the value. The others briefly poll, or better, serve the previous value kept with a soft expiry. The lock must expire in case the winner crashes, and should be released only if the token matches. Memcache-style leases do the same thing and also stop stale sets. Combine this with early refresh so hot keys rarely miss in the first place. These locks are about efficiency, not correctness.

First, network isolation. Nodes live in private subnets, and security groups allow only app servers and other nodes on the client port and the cluster bus port. Never expose them to the internet. Turn on TLS for client and replication traffic, including the bus where supported. Use ACLs, available since Redis 6, so each service has its own user limited to its key prefixes and needed commands. Block dangerous commands such as FLUSHALL, KEYS, CONFIG and DEBUG for application users. Keep passwords in a secrets manager and rotate them. Keep protected mode on and disable the default user. Encrypt RDB and AOF files at rest. Log admin commands and authentication failures, and patch quickly, since remote-execution vulnerabilities have affected exposed instances.

Per shard I track hit ratio, p99 latency, ops per second, memory used against maxmemory, evicted and expired keys, connected clients, CPU, network bytes, replication offset lag, and migration progress. From the client side I track miss rate per key prefix, MOVED and ASK rates, timeouts, and database load caused by misses. Alerts should catch trouble before the database feels it. Examples are a hit ratio falling below baseline for several minutes, one shard's traffic or CPU far above its peers, which signals a hot key, a rising eviction rate, replication lag above the staleness budget, memory above about 80 percent, and a migration that stalls. Dashboards should put database query rate next to the cache hit ratio so the link is obvious.

Lazy expiry checks the TTL when a key is accessed and deletes it if it has expired, so an expired value is never returned and no background work is needed. On its own, though, keys that are never read again would sit in memory forever. The active sweep handles that. Several times a second, Redis samples keys from the set that have TTLs, deletes the expired ones, and repeats while a large share of the sample turns out expired, within a time budget so latency stays steady. Together they give correctness from the lazy check and memory reclamation from the sweep. Replicas do not expire keys on their own timer. They wait for deletes from the primary, though a read on a replica still reports an expired key as missing.

For a pure cache where every key can be rebuilt from the database, I would pick allkeys-lfu or allkeys-lru. LFU keeps steady popular keys better when there are scans or one-off bursts. LRU suits workloads where recent use predicts the next access. volatile-* policies only evict keys that have a TTL, so if some keys lack one, the node can fill up and start rejecting writes. They make sense only when the same instance also holds keys that must never be evicted, which I would rather put on a separate cluster. noeviction is wrong for a cache, because writes fail with an out-of-memory error once memory is full. Whatever the choice, watch the eviction rate, because steady evictions of useful keys mean the cluster is too small.

Lock-based protection reacts after the miss. One caller refreshes while the others wait or get a stale value, which adds a lock round trip and some waiting. Probabilistic early refresh, as in the XFetch approach, acts before expiry. On each read, a caller decides at random to recompute, with a probability that rises as the TTL approaches zero and with how long recomputation takes. Busy keys get refreshed by one caller just before expiry, so they effectively never miss, and no lock is needed. It needs the stored value to carry its compute time and expiry, and it may cause a few duplicate refreshes. In practice I combine them: early refresh for hot keys and a lock or single-flight as a backstop for real misses.

For a pure cache, the database is the source of truth, so persistence exists only to avoid cold starts. RDB snapshots are a good fit. A restarted node loads a recent snapshot and comes back mostly warm, which protects the database. The cost is forking: copy-on-write can use up to the memory of pages changed during the snapshot, so you need headroom, and the fork itself can briefly stall large instances. AOF with fsync is for data you cannot lose, such as a write-back queue, and adds disk I/O and rewrite overhead. Without persistence, a node that restarts empty and is still a primary could replicate an empty dataset to its replicas, so either enable persistence or make sure restarted nodes come back as replicas.

Caches create extra copies of personal data, often outside the database's access controls and deletion processes. Under India's DPDP Act and similar laws, a deletion or correction request has to reach the cache too. So user-data keys need a predictable naming scheme, say user:{id}:*, that a deletion job can invalidate, plus a TTL so missed copies age out. Cache only the fields needed, and keep sensitive identifiers such as Aadhaar or card numbers out of it, or tokenize them. Separate tenants with ACL key prefixes or separate clusters. Encrypt snapshots, and restrict who can run MONITOR or read RDB files, since both expose values. Logs and telemetry should record key patterns, not values or raw user IDs.

Asynchronous replication keeps write latency at a single local operation. The primary acknowledges right away and streams changes in the background, which suits a latency-focused cache. Synchronous replication would add a network round trip to every write and couple primary availability to replica health. The cost is that acknowledged writes can be lost on failover. WAIT numreplicas timeout lets a client block until that many replicas have acknowledged its earlier writes, which lowers the chance of loss for selected operations. It does not give strong consistency. A failover can still promote a replica that did not receive the write, and WAIT does not roll back on timeout. Use it for important write-back records, not as a consensus protocol.

At startup the client fetches the topology from a seed node with CLUSTER SHARDS, or the older CLUSTER SLOTS, and caches it. It refreshes when it receives MOVED, when a connection fails, and on a slow periodic timer as a safety net. The risk is a refresh storm. During a failover, thousands of clients all get errors and all fetch topology at once. To prevent that, combine concurrent refreshes in each client so only one request is in flight, rate-limit refreshes to something like once per second, add jitter, and spread topology queries across several nodes. A single MOVED can update just that slot right away while a full refresh runs in the background. ASK never triggers a refresh.

Usually each region runs its own independent cache cluster in front of its local database replica, because cross-region round trips would undo the latency benefit. The hard part is invalidation. A write in one region must invalidate cached copies everywhere. The common way is to drive invalidation from the database's change stream, so each region deletes keys after its local database replica has applied the change. That ordering avoids refilling from a lagging replica. The staleness budget then includes cross-region replication lag. Active-active cache replication with conflict resolution exists in some commercial products, but for a cache, independent clusters plus change-data-capture invalidation is simpler. Watch for one region's outage shifting its traffic onto another region's cold cache.

To remove a primary, first move all its slots to other primaries in small batches, using the same copy-then-switch migration as when adding a node, and watch hit ratio and database load as it goes. Once it owns no slots, move its replicas elsewhere and run CLUSTER FORGET on every node so the node is not gossiped back in. To replace a failed primary, rely on automatic failover first, then add a fresh node as a replica of the new primary so redundancy is restored. If a shard has lost all replicas, its data is gone, and the slots must be reassigned and rewarmed carefully. Never remove several nodes at once if the remaining memory cannot hold the working set.

Memcached is simple and multi-threaded. It is very efficient for plain key-value strings, and sharding is done entirely in the client. It has no built-in replication, persistence or cluster-managed failover, so losing a node means losing its keys and taking a miss spike. Redis, or the open-source fork Valkey, has data structures, replication, cluster mode with slots and failover, Lua scripting, server-assisted client caching, and ACLs, which match this design's needs: replicated shards, redirects during migration, and atomic lock primitives. Memcached is a reasonable choice for a large, simple, read-heavy cache where losing a node is acceptable. For the requirements here I would choose Redis or Valkey, and check licensing and managed-service options for the organisation.

Rendezvous hashing, also called highest random weight, scores each key against every node and picks the highest. It needs no ring or virtual nodes, balances well, and moves only the keys of a node that joins or leaves, but lookup cost grows with node count. Jump consistent hash maps a key to one of N numbered buckets with almost no memory and very even balance, but it only handles adding or removing the last bucket, so it suits numbered shards rather than arbitrary nodes. Maglev hashing builds a lookup table for fast, even mapping and is common in load balancers. For a cache with uneven nodes and planned migrations, an explicit slot table is usually the most practical choice.

1. ATo remove the need for replication
2. BTo encrypt keys before storage
3. CTo spread load evenly and share moved keys across many nodesCorrect answer
4. DTo guarantee strong consistency between replicas

Why: With few points per node the ring is uneven; many virtual nodes smooth the distribution and make the keys moved during a change come from many nodes rather than one neighbour.

1. A4096
2. B16384Correct answer
3. C65536
4. D1024

Why: Redis Cluster maps every key to one of 16384 slots and assigns those slots to primaries.

1. Aitems
2. BThe whole key
3. Corder
4. Duser42Correct answer

Why: When a key contains a non-empty {...} section, only the text inside the first pair of braces is hashed.

1. AUpdate its slot map and retry on the new node
2. BSend ASKING then the command to the target node, without updating its slot mapCorrect answer
3. CRetry on the same node after a backoff
4. DFail the request back to the application

Why: ASK is a one-off redirect for a slot that is still migrating, so the slot map stays unchanged.

1. AThrough two-phase commit
2. BOnly at snapshot time
3. CSynchronously with quorum acknowledgment
4. DAsynchronouslyCorrect answer

Why: The primary acknowledges the client first and streams changes to replicas in the background.

1. ATo encrypt keys
2. BTo improve hash distribution
3. CTo make eviction cheaper
4. DTo spread out expirations so many keys do not miss at the same momentCorrect answer

Why: Jitter prevents keys loaded together from expiring together and hitting the database all at once.

1. AThey are always kept
2. BSome may be lost if they had not reached the promoted replicaCorrect answer
3. CThey are replayed from the client
4. DThey are rolled back in the database

Why: Async replication means the acknowledgment comes before replication, so the last moments of writes can be lost.

1. ASets do not support TTL
2. BDeletes are faster than sets
3. CSets from different writers can arrive out of order and leave an older value cachedCorrect answer
4. DDeletes are replicated synchronously

Why: Invalidation lets the next reader load the current committed value, so set ordering stops mattering.

1. AA healthy cache warm-up with no risk
2. BMisses are passing through to the database, which could cause an overloadCorrect answer
3. CReplication is too fast
4. DToo few clients are connected

Why: A falling hit ratio sends more load directly to the database, so it should trigger an alert before the database fails.

1. AAll keys
2. BAbout half of the keys
3. CAbout 1/(N+1) of the keysCorrect answer
4. DNo keys move

Why: The new node takes over only its share of the ring, about 1/(N+1) of the keyspace, while modulo hashing would remap nearly all keys.

1. AEvicting only keys that have a TTL, in every policy
2. BAn exact global doubly linked list of all keys
3. CApproximation by sampling a few keys and evicting the best candidateCorrect answer
4. DRandom eviction with no access tracking

Why: Redis samples a configurable number of keys and evicts the best candidate, approximating LRU or LFU with little memory overhead; only the volatile-* policies restrict eviction to keys with a TTL.

1. AMurmurHash3
2. BCRC16Correct answer
3. CSHA-1
4. DxxHash

Why: The slot is CRC16 of the key, or of its hash tag, modulo 16384.

1. AThe key has expired
2. BThe slot is permanently served by another node, so the client should update its mapCorrect answer
3. CThe node is overloaded
4. DThe key is being migrated right now

Why: MOVED signals a lasting ownership change, so the client refreshes its slot mapping.

1. AIt returns only keys from the first slot
2. BIt runs more slowly but succeeds
3. CIt is split across nodes automatically by the server
4. DIt returns a CROSSSLOT errorCorrect answer

Why: Multi-key commands require all keys to be in the same slot, otherwise the server rejects them with CROSSSLOT.

1. AIt makes Redis strongly consistent
2. BIt blocks until the given number of replicas have acknowledged earlier writes, but failover can still lose writesCorrect answer
3. CIt rolls back writes that time out
4. DIt waits for the AOF to be written to disk

Why: WAIT lowers the risk of data loss but is not consensus, since a replica that missed the write can still be promoted.

1. ACache penetrationCorrect answer
2. BHot keys
3. CReplication lag
4. DMemory fragmentation

Why: Negative caching stops repeated lookups of missing keys from always reaching the database.

1. AThe node restarts
2. BKeys are moved to disk
3. CLeast recently used keys are deleted
4. DCommands that would use more memory return an errorCorrect answer

Why: noeviction refuses writes that need memory and returns an out-of-memory error.

1. ATo count keys per slot
2. BTo settle conflicting slot ownership, where the higher epoch wins and stale primaries are fencedCorrect answer
3. CTo schedule snapshots
4. DTo encrypt the cluster bus

Why: A newly promoted replica takes a higher epoch, so after a partition the old primary sees it, steps down, and drops its writes.

1. AIt guarantees strong consistency
2. BIt lets only one caller per key, per scope, load from the database while others wait or reuse the resultCorrect answer
3. CIt replicates the value to all nodes
4. DIt evicts the key early

Why: Coalescing turns N simultaneous loads of the same key into one load.

1. ASwitch to noeviction
2. BIncrease the key's TTL
3. CServe it from a short-TTL in-process L1 cache or split it into several copies across slotsCorrect answer
4. DMove it to a hash tag

Why: L1 caching and key splitting spread or absorb the load instead of sending it all to one primary.

1. AAbout 1 TB
2. BAbout 1 GB
3. CAbout 10 GB
4. DAbout 100 GBCorrect answer

Why: 100,000,000 times 1 KB is about 100 GB, and real memory use is higher once per-key overhead and fragmentation are added.

1. ACreate an ACL user with key patterns and an allowed command listCorrect answer
2. BTurn off persistence
3. CUse hash tags
4. DRename the cluster

Why: Redis ACLs, available since version 6, control per-user command categories and key patterns.

1. AOnly keys on replicas
2. BAll keys in the cluster
3. COnly keys in the slot being movedCorrect answer
4. DOnly keys that have TTLs

Why: Moving slots a few at a time limits disruption to the fraction of data in those slots.

1. AIt supports deletes natively
2. BIt has no false positives
3. CIt has no false negativesCorrect answer
4. DIt stores full values

Why: If the filter says an ID is absent, it is definitely absent, while false positives just fall through to normal lookups.

1. AAny key
2. BOnly keys that have a TTL setCorrect answer
3. COnly keys without a TTL
4. DOnly keys in hash tags

Why: volatile-* policies only consider keys with an expiry, so a cache full of keys without TTLs can fill up.

1. AExpired keys that are never accessed again would never be freedCorrect answer
2. BIt blocks the event loop
3. CIt breaks replication
4. DIt can return expired values

Why: The active sweep reclaims memory held by expired keys that no client reads again.

1. AASKING
2. BREADONLYCorrect answer
3. CREPLICAOF
4. DCLIENT TRACKING

Why: Without READONLY, a replica redirects reads to its primary with MOVED.

1. AStops accepting writes after the node timeoutCorrect answer
2. BDeletes all its data immediately
3. CPromotes itself to a higher epoch
4. DKeeps accepting writes indefinitely

Why: This caps how long it can diverge from the majority side, which may have promoted a replica.

1. AIt doubles every TTL
2. BIt blocks all readers until refresh finishes
3. CIt locks the key in the database
4. DReaders randomly recompute before expiry, more often as expiry nears, so one refresh usually happens before the missCorrect answer

Why: Spreading refresh decisions out over time means hot keys are renewed before they expire, without locks.

1. AIt compresses data in RAM
2. Bfork uses copy-on-write, so pages modified during the snapshot get duplicatedCorrect answer
3. CIt loads the AOF at the same time
4. DReplicas send their data back

Why: Under heavy writes, copy-on-write can come close to doubling memory for the pages that change.

1. AUNLINKCorrect answer
2. BEXPIRE 0
3. CFLUSHDB
4. DDEL

Why: UNLINK removes the key from the keyspace right away and frees its memory in a background thread.

1. ACLUSTER SETSLOT
2. BKeyspace hashing
3. CCLIENT TRACKING (server-assisted client-side caching)Correct answer
4. DMONITOR

Why: With tracking turned on, the server remembers which keys a client read and notifies it when they change.

1. AAlways 6380
2. BA random port
3. CThe data port plus 1
4. DThe data port plus 10000Correct answer

Why: Nodes gossip and coordinate failover over the client port plus 10000, for example 16379, so firewalls must allow it.