Active-Active Configuration

A CTO looks at the monthly bill. Two beefy database servers, $15,000 each per month. One serves all traffic. The other sits idle, waiting for a failure that might never come. That's $15,000/month for insurance.

"Can't we use both?" the CTO asks. "Why not split the traffic between them and get double the throughput for the same cost?"

That's the appeal of active-active. Both nodes serve traffic simultaneously. Reads AND writes. No idle hardware. If one fails, the other absorbs the full load, it was already handling half, so it just handles more. No dramatic failover, no promotion ceremony, no DNS changes. The surviving node was already active.

Cloudflare runs active-active across hundreds of data centers. GitHub moved to active-active across multiple data centers after years of active-passive. Amazon's DynamoDB global tables are active-active across regions. Stripe processes payments through active-active systems because they cannot afford any single point of failure.

But here's what the CTO didn't ask: "What happens when both nodes modify the same data at the same time?" That question is where active-active gets complicated fast.

In active-passive, the architecture is simple: one source of truth (the active), one backup (the passive). Data flows in one direction. Conflicts are impossible because only one node writes.

In active-active, both nodes accept writes. Data flows in both directions. Conflicts are not only possible, they're inevitable at scale.

The fundamental trade-off: Active-active gives you better utilization and faster failover at the cost of conflict management complexity and weaker consistency guarantees.