Challenge 3: Trace a Failover — Possible Solution
====================================================================

1. The primary crashes (or becomes unreachable due to a network
   issue). The two remaining secondaries stop receiving new oplog
   entries from it, since it's no longer there to produce them.

2. The secondaries notice the primary is unreachable (via missed
   heartbeats) and call for an election, since the replica set can no
   longer accept writes without a primary.

3. Each remaining secondary votes — for itself or for whichever
   candidate has the most up-to-date data (measured by how far each
   member's oplog has progressed). With 2 members remaining out of an
   original 3, a majority is 2 votes — achievable as long as both
   surviving members agree, since 2 out of the original 3 is more than
   half.

4. One secondary is elected the new primary. It transitions roles and
   begins accepting writes; the other remaining member continues as a
   secondary, now replicating from the NEW primary.

5. There is a brief window — typically just a few seconds — between
   the old primary going down and a new one being elected, during
   which the replica set has NO primary and cannot accept any writes
   at all (reads from secondaries, if read preference allows it, can
   still succeed during this gap). Any application write attempted
   during this window fails or times out and should be retried once a
   new primary is elected.

6. Once elected, the new primary starts accepting writes again, the
   application's driver detects the new primary (often automatically,
   given it's connected via the replicaSet connection string, not a
   single host), and normal operation resumes — all without a human
   manually promoting anything.

7. When the old primary eventually comes back online, it rejoins the
   set as a secondary (not automatically reclaiming primary status),
   and catches up on any oplog entries it missed while it was down.