Data is an asset for an organization because it drives the whole business. Data provides critical business insights into what’s important and what needs to be changed. Organizations also need to securely save and serve their clients’ data on demand. Timely access to the required data under varying conditions (increasing reads and writes, disks and node failures, network and power outages, and so on) is required to successfully run an online business.

We need the following characteristics from our data store:

  • Availability under faults (failure of some disk, nodes, and network and power outages).
  • Scalability (with increasing reads, writes, and other operations).
  • Performance (low latency and high throughput for the clients).

It’s challenging, or even impossible, to achieve the above characteristics on a single node.

Replication

Replication refers to keeping multiple copies of the data at various nodes (preferably geographically distributed) to achieve availability, scalability, and performance. In this lesson, we assume that a single node is enough to hold our entire data. We won’t use this assumption while discussing the partitioning of data in multiple nodes. Often, the concepts of replication and partitioning go together.

However, with many benefits, like availability, replication comes with its complexities. Replication is relatively simple if the replicated data doesn’t require frequent changes. The main problem in replication arises when we have to maintain changes in the replicated data over time.

Additional complexities that could arise due to replication are as follows:

  • How do we keep multiple copies of data consistent with each other?
  • How do we deal with failed replica nodes?
  • Should we replicate synchronously or asynchronously?
    • How do we deal with replication lag in case of asynchronous replication?
  • How do we handle concurrent writes?
  • What consistency model needs to be exposed to the end programmers?

We’ll explore the answer to these questions in this lesson.