Your company runs two data centres and wants automatic database failover between them. What is missing?

What the interviewer is testing

Whether you know that two participants cannot form a majority, which is the most common structural flaw in two-site designs.

The problem

With two sites, a network partition between them is indistinguishable from the other site failing. Each side sees the other as unreachable. Each concludes it should take over. Both accept writes.

That is split brain, and it is worse than an outage because it does not announce itself — both halves appear healthy, both serve traffic, and the damage surfaces when the partition heals and two divergent histories cannot be merged.

No quorum rule helps, because any rule one side can satisfy, the other can satisfy identically.

Why the other options fail

Faster health checks make it worse. A shorter threshold means failing over on transient network events, which are far more common than genuine host failure. GitHub's 2018 incident was triggered by a 43-second partition and took over 24 hours to reconcile.

Synchronous replication ensures no data loss during normal operation and does nothing about who gets to be primary during a partition. It is orthogonal.

The fix

A third site as a witness or arbiter. It holds no data and participates in the quorum, so a partition produces exactly one majority and only one side can promote. It can be a small instance in a third region — this is cheap.

Two alternatives worth knowing:

Manual failover with fencing. Slower to recover and correct: a human decides, and the procedure positively prevents the old primary from resuming writes.

Regional partitioning, where each site owns a subset of the data as sole writer. There is no contested leadership because no record has two possible owners. This is frequently the best answer for multi-region systems and is under-used.

What a strong answer adds

Fencing at the storage layer regardless of which option is chosen: a deposed primary that resumes after a pause must have its writes rejected by the resource, not merely be told it is no longer leader. Without that, a paused process is a data corruption path that no timeout prevents.

Common weak answers

Tuning the failover timeout. Adding a load balancer, which does not arbitrate leadership.