The one thing to understand first
By default every standby streams WAL directly from the primary, so a hundred replicas means a hundred walsender connections on the primary and a hundred copies of every byte crossing your network links. PostgreSQL gives you two knobs to reshape that picture: <a class="sev1-termlink" href="https://thesev1database.com/glossary/cascading-replication/" title="Cascading replication">cascading replication lets a standby relay WAL to other standbys (a tree instead of a star), and delayed standbys deliberately hold a replica a fixed interval behind the primary so it becomes a time machine you can use to undo human error. Both are pure topology and timing choices on top of the same streaming-replication machinery the earlier Pathway 04 lessons described.
This extends Pathway 04’s streaming-replication and recovery lessons by showing how to arrange standbys into tiers and how to intentionally lag one for protection.
The mechanism: a standby can also be a sender
A walsender is not exclusive to the primary. When you point one standby’s primary_conninfo at another standby instead of the primary, the upstream standby starts a walsender (the same src/backend/replication/walsender.c machinery) and forwards WAL as it receives and writes it. The upstream must have hot_standby = on and spare max_wal_senders slots. The result is a cascade: primary → tier-1 standby → tier-2 standbys, each level offloading fan-out from the level above. The key constraint: only standbys connected directly to the primary can be synchronous — cascaded standbys never count toward synchronous_standby_names, because the primary only knows about its direct children.