Distributed Databases Basics: Complete Beginner's Guide

A distributed database stores its data across many computers, called nodes, instead of one big machine. It looks like one system to your application, but data is split or copied across several servers — as in Spanner, DynamoDB and CockroachDB.

One computer has hard limits on data, users and uptime: when it dies, everything stops. Spreading data across nodes removes those limits: add machines for capacity, and the database survives individual servers failing.

Key Concepts

• Node — one server in the database cluster. A cluster might have 3 nodes or 3,000.
• Replication — keeping copies of the same data on multiple nodes. Replication factor 3 means every piece of data lives on 3 nodes, so 2 can fail without losing anything.
• Sharding — splitting the dataset so different nodes hold different slices (users A–M on one shard, N–Z on another). Sharding grows capacity; replication grows safety.
• Consistency models — strong consistency means every read sees the latest write; eventual consistency means reads may briefly see stale data but converge over time.
• CAP theorem — during a network partition, a system must choose between consistency and availability — it cannot have both at once.
• Quorum reads/writes — a write succeeds after W replicas acknowledge; a read consults R replicas. If R + W exceeds the replication factor N, reads always overlap a fresh write.

Formulas

• Quorum rule: choose W and R so that R + W > N. For N = 3, W = 2 and R = 2 gives 2 + 2 = 4 > 3, so every read overlaps at least one node holding the latest write.
• Write latency: a quorum write waits for the W-th fastest acknowledgement: with replies at 20 ms, 35 ms and 200 ms, a W = 2 write completes in 35 ms — the slow replica does not block it.
• Storage cost: total storage = data size × replication factor. One terabyte with replication factor 3 consumes 3 TB of disk across the cluster.

Worked Example

A cluster stores profiles with N = 3, W = 2, R = 2. A write updates a profile, then a read fetches it immediately. Does the read see the new value?

1. Check the rule: R + W = 2 + 2 = 4 > 3. It holds.
2. The write is acknowledged by 2 of 3 replicas — say A and B hold the new value, C still has the old one.
3. The read asks 2 replicas; every possible pair (AB, AC, BC) includes A or B, so at least one has the new value.
4. The database compares versions and returns the newest — the read always sees the fresh write, without waiting for every replica.

Common Misconceptions

• "Replication and sharding are the same." Replication copies the same data for safety; sharding splits different data for capacity. Production systems use both together.
• "Eventual consistency means data is lost." It only means delayed: replicas converge to the same value shortly after writes stop.

Real-World Applications

• Global apps: social networks shard user data across regions so a user in Mumbai reads from nearby servers.
• E-commerce: carts and inventory use quorum replication so an order survives a server crash mid-checkout.
• IoT platforms: sensor readings stream into distributed stores absorbing millions of writes per second no single machine could handle.

Distributed databases trade one big fragile machine for many small cooperating ones. Learn the quorum rule R + W > N, know sharding from replication, and respect the CAP trade-off — and you can reason about any distributed store, from Cassandra to Spanner.