Data Replication and Distribution

Replication is keeping the same data on more than one node and keeping those copies in agreement. Distribution is spreading data and traffic across many nodes, often across regions, so no single machine holds everything or serves everyone. The two ideas work together. Replication gives you redundancy and read scale; distribution gives you geographic reach and write scale. A real system usually does both at the same time.

The building block is the replication log. When a primary node accepts a write, it records that change and ships it to its replicas. How it records and ships that change is what separates the techniques. Physical replication copies the raw on-disk byte changes, so a replica is an exact block-level twin of the primary. Logical replication ships the change as a row-level event ("user 42 changed email to X"), which lets replicas run different storage engines or even different schema versions. Write-ahead log replication and streaming replication feed the replica directly from the primary's WAL as it is written, which is why they are fast and lossy-resistant. Log shipping batches up log segments and sends them on a schedule, which is simpler but lags more.

Change data capture sits slightly to the side of all this. Instead of replicating a database to another identical database, CDC reads the same replication stream (often the MySQL binlog or the Postgres WAL) and turns it into an event feed that other systems consume. That is how a transactional database keeps a search index, a cache, an analytics warehouse, and a downstream microservice in sync without anyone writing brittle dual-write code.

Once you have more than two nodes, you have to decide how changes flow between them. The simplest is point-to-point, one primary streaming to one replica. Scale that up and you reach for a topology. In a star or hub-and-spoke layout, a central node fans changes out to many leaf nodes, which is easy to reason about but makes the hub a bottleneck and a single point of failure. A ring passes changes node to node around a loop, which spreads load but adds latency with each hop and breaks awkwardly when a node in the ring dies. A mesh or many-to-many topology lets every node talk to every other node, giving the best resilience at the cost of much harder conflict handling.

The topology question is tightly linked to write configuration. Active-passive (active-standby) keeps one node taking writes while others stand ready to take over on failure; it is simple and conflict-free but wastes the standby capacity. Active-active lets multiple nodes accept writes at once, which gives you write scale and lets each region serve its own users with local latency. The hard part is that active-active and multi-master designs invite conflicts when two nodes change the same record concurrently, so you need conflict resolution rules, and bidirectional replication between two masters has to guard against changes echoing back and forth forever.

There is no universally correct topology. A small service is well served by a primary with async read replicas. A global product that must accept writes in every region needs active-active multi-master across a mesh, and must accept the conflict-resolution complexity that comes with it.

Netflix runs Cassandra in an active-active, multi-region setup so that a failed AWS region does not interrupt streaming; consistent hashing spreads data across the ring and replication keeps copies in every region. Their teams routinely practice failing out of a region to prove the distribution actually works under stress.

Uber and large e-commerce platforms lean on change data capture from their transactional databases to keep search, analytics, fraud detection, and caches fresh without dual writes. The same binlog or WAL stream that feeds a replica also feeds a CDC pipeline into Kafka, which fans the changes out to dozens of downstream consumers.

Postgres and MySQL shops typically run a primary with semi-synchronous or asynchronous streaming replicas for read scaling and fast failover, then add cross-region replicas for disaster recovery. Globally distributed databases such as Spanner and CockroachDB push the idea further, using synchronous replication across regions with consensus so they can offer strong consistency worldwide, accepting the higher write latency that comes with coordinating across the planet. The pattern across all of them is the same: pick a replication mode for your durability needs, pick a topology for your write pattern, and pick a distribution strategy for your geography.