Exercise 2: Automatic Failover Here vs. postgres1-11's Own Replication — Possible Solution
====================================================================

HOW FAILOVER WORKS HERE
------------------------------
Per this chapter, "if a node holding a primary shard goes down, one of
its replicas is automatically promoted to primary, and the cluster
keeps serving both reads and writes with no manual intervention
required." When a node carrying a primary shard fails, the cluster's
own coordination logic detects this and automatically selects one of
that shard's own existing replicas (already living on a different
node) to be promoted to the new primary — this happens as a normal,
built-in part of how the cluster manages itself, without any separate
tool or manual step needed.

HOW THIS DIFFERS FROM POSTGRES1-11'S OWN REPLICATION MATERIAL
------------------------------
Per this chapter, "Postgres's own streaming replication requires
deliberate setup — a tool like Patroni or repmgr for automatic
failover, per that chapter's own honest material. Here, replica-based
redundancy and automatic failover are built into the cluster's own
core coordination logic from the start, not something layered on
afterward with a separate tool." Per postgres1-11 itself, Postgres
"doesn't include automatic failover out of the box... a raw streaming
replica setup requires manual promotion (pg_promote()) unless a
separate HA-management tool is layered on top." Streaming replication
itself (copying data to a standby) is a genuine, built-in Postgres
capability — but the DECISION to actually promote a standby to primary
when the original primary fails is NOT automatic in Postgres's own
core system; it requires either a human manually running pg_promote(),
or a genuinely separate, additional piece of software (Patroni,
repmgr) specifically responsible for detecting the failure and
triggering that promotion.

THE KEY STRUCTURAL DIFFERENCE
------------------------------
The core difference isn't whether replication/redundancy exists at
all — both systems genuinely have that. The difference is WHERE the
failure-detection-and-promotion logic actually lives. In Postgres, that
logic is either a manual human action or an ADDITIONAL, separate tool
sitting outside Postgres's own core engine. In Elasticsearch/
OpenSearch, per this chapter, that exact same logic — detecting a
failed node and promoting a replacement primary — is part of the
cluster's OWN built-in coordination mechanism (the same cluster-
manager/consensus material this chapter also covers), with no separate
tool required at all. This is the concrete, mechanical instance of
search1-1's own "distributed by design from day one" claim, applied
specifically to failover.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states how failover actually works in each system using both
chapters' own wording, and identifies the precise structural
difference — built into the core coordination logic here, vs. requiring
either a manual step or a genuinely separate tool in Postgres — rather
than just asserting "one is more automatic" without explaining why.