What the application must do.
WHAT HAPPENS DURING FAILOVER
Connections are dropped Writes fail for a period A different server becomes primary
WHAT THE APPLICATION MUST HANDLE
Connection errors, without crashing Retrying safely Reconnecting to the new primary
WHAT MAKES RETRY SAFE
Idempotent operations, or transactions that either committed or did not.
WHY THAT MATTERS
Retrying a payment that actually succeeded charges twice.
WHAT TO DO ABOUT UNCERTAIN OUTCOMES
Check before retrying, using a unique key for the operation.
WHAT CONNECTION HANDLING SHOULD DO
Detect dead connections Discard them from the pool Reconnect
WHAT TO AVOID
Caching the primary's address indefinitely.
WHAT TO USE INSTEAD
A proxy, a virtual address, or discovery.
WHAT TO TEST
Failover, deliberately, with the application running.
WHY
It is the only way to know what actually happens.
WHAT USUALLY BREAKS
Connection pools holding stale connections Long timeouts making the outage appear longer Retries that duplicate work
WHAT TO SET
Short connection timeouts, so failure is detected quickly.
WHAT TO SHOW USERS
A clear message rather than an error page.
WHAT TO LOG
The failover, so the incident is explicable afterwards.
