The one thing to understand first
By default PostgreSQL replication is asynchronous: a primary commits once its own WAL is durable, without waiting for any standby. If the primary then fails before a standby received the latest WAL, those last transactions are lost. Synchronous replication makes the primary wait for standby confirmation before reporting commit success, eliminating that data-loss window — at the cost of commit latency.
Synchronous replication trades latency for durability — but if you don’t provision enough standbys, it secretly also trades away availability: the same “wait for confirmation” that prevents data loss will hang every commit when there’s no one left to confirm.
Layer 3 — Watch it happen on your own database
One catalog tells you which standbys are actually counting toward your durability guarantee: