Keep declared services running through the failures your deployment covers.
Availability starts with an explicit failure model. Identify which services must continue and which machine, storage, or site failures the deployment must survive.
Place both data and required service roles accordingly. Several copies on one machine do not protect against losing that machine.
Track degraded redundancy, unavailable peers, and recovery progress. A successful failover must preserve the workspace's identity, permissions, integrity, and committed history.
Workspace-aware routing finds a reachable serving candidate. That candidate still needs authority, keys and sufficient state to execute the requested work.
For example, a deployment intended to survive one site failure needs an eligible serving host and protected data outside that site.
A single-node deployment remains useful, but has a different guarantee from a deployment spanning independent locations. Recovery time and possible data loss depend on the selected policies and topology.
Read about replication and backup and restore when deciding which failures to cover.
A transaction can require additional encrypted block copies before its branch head becomes visible. Host replication has a separate timing policy. Choose synchronous publication conditions for stronger replication evidence, or asynchronous placement for later convergence. The selected condition determines what publication waits for and which failures the deployment can cover.
Replication without widening trust explains capacity, regional serving, repair and these transaction tradeoffs.
Developer reference
Specify independent failure domains, Host/custodian placement, serving eligibility and publication durability conditions. Desired replica count is not observed replication success.
A ciphertext survivor preserves bytes. Query recovery additionally needs an authorized Host, decryption authority, discoverable committed roots and reachable referenced blocks. Test the complete dependency set after losing a process, machine or site.
RPO bounds accepted data loss; RTO bounds service restoration time. Their values depend on the actual topology and acknowledged durability policy. Multiple processes in one failure domain do not provide site-level resilience, and a complete archive does not itself constitute an online serving replica.