Challenge 2: Explain Redis's Failover Gap — Possible Solution
====================================================================

Plain Redis replication (REPLICAOF) only handles ONE job: keeping a
replica's data continuously synced with its primary. It has no
built-in logic for detecting that the primary has actually failed, no
voting or election mechanism among replicas, and no automatic
mechanism to promote a replica to take over as the new primary. If the
primary simply disappears, the replicas keep being replicas
indefinitely — nothing about plain replication changes that on its
own.

This is a deliberate architectural difference from MongoDB, where
election logic (majority voting, automatic promotion) is BUILT INTO
the replica set mechanism itself, per mongodb2-5. Redis instead
separates these two concerns into two different tools: replication
(REPLICAOF) handles data syncing only, while a completely separate
system, SENTINEL, is responsible for monitoring the primary's health,
detecting a genuine failure (requiring agreement among multiple
Sentinel instances, to avoid a false alarm from one Sentinel's own
network issue), and then performing the actual promotion and
reconfiguration of the other replicas.

THE COMPONENT THAT FILLS THE GAP: Sentinel. Without running Sentinel
(or an equivalent, like a managed cloud Redis service's own failover
tooling) alongside plain replication, a Redis primary going down means
manual intervention is required to promote a replica — there is no
automatic recovery built into replication by itself.