What Is Data Replication in a Distributed System? A Guide
Data replication in a distributed system means keeping full copies of the same data on several separate nodes, so one failed disk, server or rack doesn't take your data offline. HDFS, for example, stores three copies of every block unless you tell it otherwise.
TL;DR:
- Replication keeps complete, identical copies on different nodes. Any surviving copy can serve your reads, with nothing to rebuild.
- Synchronous replication waits for every copy before confirming a write. Asynchronous replication confirms first and copies later, which leaves a small window for data loss.
- The replication factor is the number of copies. Three is the common default (HDFS, many Cassandra setups), and it costs 3x the raw storage.
- Erasure coding is the main alternative: it stores data and parity pieces instead of full copies. AIOZ Storage uses erasure coding.
Updated Oct 19, 2026: tightened the post around replication in distributed systems, added replication designs, quorum math, a diagram and a "replication is not a backup" section, and corrected the AIOZ Storage section: AIOZ Storage protects objects with erasure coding.
What Is Data Replication in a Distributed System?
A distributed system spreads data and work across many machines. Replication is the simplest way to keep that data safe there: you store the same bytes more than once, on machines that don't fail together. If one copy becomes unreachable, another copy answers the request.
The reason is scale, and the HDFS design guide puts it plainly: "Hardware failure is the norm rather than the exception." With hundreds or thousands of servers, some disk or node is failing at any moment, and replication lets your system keep working through that.
How Does Data Replication Work?
Every replicated system answers two questions: who accepts writes and how the copies get updated. In practice you'll meet three common designs, and each one answers those questions differently.
- Single leader (primary and standby). One node takes all writes and ships changes to the others. PostgreSQL streaming replication works this way: standbys follow the primary's write-ahead log.
- Leaderless. Any replica can take a write. Cassandra's documentation says: "All replicas are equally important; there is no primary or master replica." Clients read and write to several replicas and compare answers.
- Block placement by a coordinator. In HDFS, files are split into blocks, and "The NameNode makes all decisions regarding replication of blocks." It also re-copies blocks when a DataNode stops sending heartbeats.
Which design fits you depends on your write pattern: a single leader is easy to reason about, while a leaderless design keeps accepting writes when some nodes are down.
Synchronous vs Asynchronous Replication
The second choice is when a write counts as done. That choice decides how much data you can lose in a failover.
| Synchronous | Asynchronous | |
|---|---|---|
| Write confirmed when | the replicas you require have it | the first node has it |
| Data loss on failover | none for confirmed writes, unless every required copy fails | recent writes not yet shipped |
| Write latency | higher, grows with distance | lower |
| Typical use | payments, ledgers | cross-region copies, read replicas |
PostgreSQL's documentation shows both sides: with synchronous replication, "each commit of a write transaction will wait until confirmation is received" from both the primary and the standby. Its file-based log shipping is asynchronous, so "there is a window for data loss" if the primary fails before records are shipped. You trade latency for safety, and you can set it per system.
What Is a Replication Factor?
The replication factor is the number of copies you keep. In HDFS the dfs.replication setting defaults to 3, and you can change it per file. With three copies, HDFS puts one replica on the writer's node or rack, and the other two on two different nodes in one remote rack. One rack can burn down and your block still survives. IPFS pinning services make the same choice about how many copies to keep, as multi-node pinning replication shows.
Leaderless systems add a second number: how many replicas must answer. Cassandra calculates a quorum as (sum of replication factors / 2) + 1, rounded down. With a replication factor of 3, a quorum is 2 nodes, so the cluster "can tolerate 1 replica down" and still serve quorum reads and writes.
The cost is easy to work out: if you store 10 TB with a replication factor of 3, you pay for 30 TB of disk, plus the network traffic to write every byte three times.
Replication vs Erasure Coding
That 3x bill is why large storage systems also use erasure coding. Instead of full copies, the system splits an object into data pieces, computes parity pieces, and stores each piece on a different node. Any k of the n pieces rebuild the object.
The HDFS erasure coding guide gives the numbers: "the default 3x replication scheme in HDFS has 200% overhead," while typical erasure coding setups use "no more than 50%." The price is extra work on failure, because a replica is ready to read, but a lost erasure-coded piece has to be rebuilt from k other pieces. So you'll often see replication for hot, small, busy data, and erasure coding for large or colder data.
Replication Is Not a Backup
Replication protects you from hardware failure, but it doesn't protect you from your own mistakes. If you delete a file or a script overwrites it, every replica gets the same change within milliseconds. Ransomware that encrypts your files gets replicated too.
For that you need separate copies with history: object versioning, write-once object lock, and a backup plan such as the 3-2-1 backup rule. Replication and erasure coding keep data available, while backups let you go back in time.
How AIOZ Storage Handles Redundancy
AIOZ Storage protects each object with Reed-Solomon erasure coding, not full replicas. After server-side encryption, the object is split into data pieces plus parity pieces, and the pieces are stored on different nodes. Any k of the n pieces rebuild the object, so it survives the loss of several pieces. No single node holds a complete copy of your file.
The network also audits its nodes and repairs lost pieces, so redundancy is restored after a node drops out. You don't turn any of this on, and a plain upload with the AWS CLI, as shown in the AIOZ Storage docs, is enough:
# Recent AWS CLI versions: send Content-Length (see our CLI quickstart)
export AWS_REQUEST_CHECKSUM_CALCULATION=WHEN_REQUIRED
aws s3 --endpoint-url https://s3.aiozstorage.network cp /path/to/file s3://bucket-nameWhat we don't publish yet: the exact k and n values and the resulting fault-tolerance percentage. The same backup rule applies here too: erasure coding won't undo a delete, so keep an independent copy of data you can't lose. Our redundancy explainer covers what that protection includes and what you still back up yourself.
Next step: upload your first object from the AIOZ Storage docs.
Frequently Asked Questions
What is data replication in simple terms?
It means keeping identical copies of the same data on separate machines. If one machine fails, you read from another copy.
What's the difference between synchronous and asynchronous replication?
Synchronous replication confirms a write only after the required replicas have it, so confirmed writes survive a failover. Asynchronous replication confirms first and copies afterward, which is faster but can lose the newest writes.
What replication factor does HDFS use by default?
Three. The dfs.replication setting defaults to 3, and HDFS spreads the copies across two racks.
What is a quorum in replication?
The number of replicas that must answer a read or write. Cassandra computes it as (sum of replication factors / 2) + 1, so a replication factor of 3 needs 2 replicas and tolerates 1 down.
Is replication better than erasure coding?
Neither wins everywhere: replication is simpler and faster to recover, at 3x storage for three copies. Erasure coding gives similar protection for far less storage, but rebuilding a lost piece takes more work.
Is data replication the same as a backup?
No. Replication copies deletes and overwrites too. A backup keeps an independent, older copy you can restore from.
Does AIOZ Storage use replication or erasure coding?
Erasure coding. Each object is encrypted, split into data and parity pieces, and spread across different nodes, and any k of the n pieces rebuild it.
Related Reading
- What Is Erasure Coding? How It Compares to Replication - the alternative to full copies, with real numbers from Storj and Sia.
- How AIOZ Storage protects your objects - what the network covers for you, and what you still back up yourself.
- Data Durability vs Availability, and What 11 Nines Means - the two guarantees replication and erasure coding work toward.
- S3 Eventual Consistency vs Strong Consistency Explained - when every reader sees a write once data lives on many nodes.
- 3-2-1 backup rule explained - how redundancy fits into a full backup plan.
- What Is S3 WORM Storage? Object Lock Modes and Setup - protection against deletes and ransomware, which replication can't give you.
- What Is S3 Object Storage? How It Works, Explained - the object storage model these techniques protect.
- AIOZ Storage vs Storj: Two DePIN Platforms Compared - two decentralized S3-compatible services side by side.
References
Related Content
What Is Distributed Storage? How It Works, With Examples
Distributed storage keeps data on many independent nodes that act as one system. See how it works, replication vs erasure coding, its types and trade-offs.
What Are Egress Fees? How Download Charges Work in Storage
Egress fees are charges for data leaving a storage provider's network. See what triggers them, how to estimate them, and what AIOZ Storage's docs say.
Object Storage Vector Database: Where AIOZ Storage Fits
An object storage vector database keeps vectors in the storage layer, not a cluster. See how it differs, when to pick it, and where AIOZ Storage fits in.
AIOZ Storage Vector Database Pricing: What You Pay For
AIOZ Storage vector database pricing line by line: upload, storage, queries, data searched and data returned, with a worked monthly example you can reuse.
How to Create a Bucket and Upload a File on AIOZ Storage
Create a bucket and upload a file on AIOZ Storage in five steps: sign up, set a passphrase, add credits, and upload. Plus what the passphrase cannot recover.
AIOZ Storage Rate Limit: Working Within 100 Requests/s
The AIOZ Storage rate limit is 100 requests per second. See what the docs do and don't say, and how to stay under it with boto3 retries and a limiter.