|
Latest articles
If you’re not a subscriber, here’s what you missed this month.
 |
Database Schema Design Simplified: Normalization vs Denormalization
SQL vs NoSQL: Choosing the Right Database for An Application
To receive all the full articles and support ByteByteGo, consider subscribing:
Every modern application relies on data, and users expect that data to be fast, current, and always accessible. However, databases are not magic. They can fail or slow down under load. They can also encounter physical and geographic limits, which is where replication becomes necessary.
Database Replication means keeping copies of the same data across multiple machines. These machines can sit in the same data center or be spread across the globe. The goal is straightforward:
Increase fault tolerance.
Scale reads.
Reduce latency by bringing data closer to where it's needed.
Replication sits at the heart of any system that aims to survive failures without losing data or disappointing users. Whether it's a social feed updating in milliseconds, an e-commerce site handling flash sales, or a financial system processing global transactions, replication ensures the system continues to operate, even when parts of it break.
However, replication also introduces complexity. It forces difficult decisions around consistency, availability, and performance. The database might be up, but a lagging replica can still serve stale data. A network partition might make two leader nodes think they’re in charge, leading to split-brain writes. Designing around these issues is non-trivial.
In this article, we walk through the concept of replication lag and major replication strategies used in distributed databases today. We will cover single-leader, multi-leader, and leaderless replication models, breaking down how each works, what problems they solve, and where they fall apart.
 |
