Before a standby can take traffic
Exclude the old writer, acquire the current term, replay durable state and require fresh whole-node readiness.
When an active broker stops responding, a standby needs evidence that it can safely own writes. A heartbeat cannot prove that the old writer has lost access to storage or external destinations.
CitusIO Enterprise uses an active–standby pair for the same workload. External fencing excludes the old active. The new owner acquires the writer term, replays durable state, creates fresh rings and reports readiness before the router assigns traffic.
Readiness is a whole-node decision
nginx, the broker/bridge processes, local rings and store ownership must agree. The daemon exposes node/shard readiness, current writer ownership and supporting frontier/generation gates. Liveness can detect suspicion; traffic routing waits for the ownership and recovery proof.
Plan the failed boundary
Record how the deployment excludes the old writer, obtains a newer term, validates durable replay and reconciles pending external effects. Rehearse loss of store access, stale-active rejection, owner replacement and uncertain term. Keep traffic withdrawn while a required gate is unknown.
Kubernetes can restart a pod and inspect a readiness signal. It cannot grant writer ownership or recreate a missing replay frontier. The current model provides whole-node active–standby recovery; active-active writers, horizontal broker sharding and transparent TCP migration are outside its scope.
Use the HA guide, Enterprise skill and the private deployment’s actual fencing/router contract before moving traffic.