# Erasure coding > Erasure coding stores data as fragments plus computed recovery fragments, allowing missing pieces to be reconstructed without keeping multiple full copies. In system design interviews, it is a storage-cost choice for large, durable objects, with trade-offs in read latency, repair traffic, and operational complexity. Source: https://sysround.com/concepts/erasure-coding Updated: 2026-11-05 ## How erasure coding works Split data into stripes, each containing k data fragments, and compute m parity fragments for each stripe. With a Reed–Solomon code, any k of the k + m fragments can reconstruct the original stripe. A 6+3 scheme stores nine fragments and tolerates any three missing fragments per stripe. Storage overhead is (k + m) / k. A 6+3 scheme uses 1.5 times the original data size, excluding metadata and padding; three-way replication uses 3 times the original size. This compares capacity, not equivalent durability: durability also depends on placement, failure rates, and repair speed. Many implementations use systematic coding, which keeps the original data fragments alongside parity. Healthy reads can fetch the needed data fragments directly; a missing data fragment requires fetching enough other fragments and decoding. Small range reads therefore need not reconstruct the entire object. Place fragments across independent failure domains, not just different disks. For example, nine fragments distributed evenly across three racks lose three fragments when one rack fails, which a 6+3 code can tolerate. Availability-zone or region failures require their own placement analysis. When a fragment disappears, a repair worker reconstructs it and writes a replacement elsewhere. Conventional Reed–Solomon repair may read k surviving fragments to rebuild one missing fragment, so recovery can consume much more network traffic than the replacement fragment's size. Checksums help detect corrupt fragments before they are used for reconstruction. Define when an upload becomes durable and visible. Acknowledging after only k fragments are stored leaves no margin for another fragment loss; the write policy must establish the required redundancy first, or retain a durable replicated staging copy. A common design replicates new uploads, then converts settled objects to erasure-coded storage before deleting the staging copies. ## Worked example: A 6+3 storage tier for uploaded photos Suppose a photo service stores 1 PB of immutable originals. Three-way replication requires 3 PB of raw capacity; a 6+3 Reed–Solomon tier requires about 1.5 PB, before metadata and padding. A 6 MB stripe becomes six 1 MB data fragments and three 1 MB parity fragments. Place three fragments in each of three racks, so one rack outage leaves the six needed for reconstruction. Conventional repair of one lost 1 MB fragment may read six surviving 1 MB fragments. Keep upload staging and metadata replicated, verify coded fragments before removing staging copies, and throttle repair against foreground traffic. This halves raw capacity relative to three copies, but does not by itself prove equivalent durability. ## Trade-offs - **Lower capacity overhead.** Erasure coding can use substantially less storage than full replication, but raw capacity savings must be weighed against CPU, network, metadata, and repair costs. - **More expensive degraded reads.** Healthy systematic reads can be direct, while missing fragments introduce additional fetches, decoding, and potentially higher tail latency. - **Repair bandwidth.** Rebuilding a missing fragment can require reading several surviving fragments, creating contention with foreground requests during failures. - **Small-write and small-object overhead.** Partial-stripe updates can require extra reads and parity writes, while tiny objects may waste space through padding and per-fragment metadata. - **Placement and coordination complexity.** Fragment placement, durable write acknowledgment, metadata protection, and safe conversion from replicated storage require explicit protocols. - **Fault tolerance is not a durability guarantee.** Tolerating m missing fragments per stripe does not establish a durability target without accounting for correlated failures, corruption, and repair time. ## When to use it in a system design interview - The design stores a large volume of durable media, backups, or other immutable objects, and storage capacity is a major cost. - The workload favors large sequential reads and writes rather than frequent small in-place updates. - Hot content can be served from caches or replicated tiers while erasure-coded storage holds the durable source. - The interviewer asks how to reduce replication overhead without giving up recovery from disk, host, or rack failures. ## How to bring it up in the interview - Start with the workload: explain why immutable object bytes fit erasure coding better than frequently updated database rows or latency-sensitive metadata. - Name a concrete code, calculate its capacity overhead, and state its fragment-loss tolerance; expect a follow-up on why you chose those parameters. - Draw fragment placement across failure domains and count how many fragments disappear in a rack or zone outage; interviewers will probe correlated failures. - Describe normal reads, degraded reads, and background repair separately, including how repair is throttled without leaving data underprotected for too long. - Explain upload acknowledgment and any replicated-to-coded transition; expect questions about crashes during conversion, checksum verification, and when old copies can be deleted. ## Common mistakes - Saying parity fragments are full backup copies, or assuming an arbitrary erasure code can reconstruct data from any k fragments. - Claiming a coding scheme is as durable as three-way replication based only on its fragment count or storage overhead. - Placing all fragments on different hosts in one rack and then claiming protection against rack failure. - Assuming every read requires decoding, or ignoring the extra work when a requested data fragment is unavailable. - Applying erasure coding to all data without considering small objects, mutable metadata, write acknowledgment, and repair bandwidth. ## Interview questions where it comes up - [Design Google Photos](https://sysround.com/questions/design-google-photos): Protecting a large collection of original photos makes storage overhead, durable upload acknowledgment, and fragment repair important design decisions. - [Design Dropbox or Google Drive](https://sysround.com/questions/design-dropbox): The durable file-content layer must balance capacity efficiency with reliable publication, recovery, and the cost of storing versioned file chunks. - [Design a video streaming service like YouTube](https://sysround.com/questions/design-youtube): Large original videos and encoded renditions make erasure coding versus replication a meaningful choice for origin-storage cost and recovery behavior. ## FAQ ### What is the difference between erasure coding and replication? Replication stores complete copies of data; erasure coding stores data fragments plus computed recovery fragments. Replication offers simpler reads and recovery, while erasure coding usually reduces storage overhead at the cost of more complex placement, decoding, and repair. ### How many failures can erasure coding tolerate? A Reed–Solomon k+m stripe can tolerate any m unavailable fragments, provided the remaining fragments are valid. That does not automatically mean m rack or zone failures: the answer depends on how many fragments each failed domain contains. ### When should I use erasure coding instead of replication? Use it when durable object capacity is expensive enough to justify the added operational work, especially for large, immutable data. Prefer replication for small mutable records, simple low-latency access, or workloads where repair and decoding costs outweigh capacity savings. A hybrid design can replicate uploads and hot data while coding settled objects. ## Related concepts - [Database replication](https://sysround.com/concepts/replication) - [Object storage](https://sysround.com/concepts/object-storage) - [Disaster recovery, RPO and RTO](https://sysround.com/concepts/disaster-recovery) - [Back-of-the-envelope estimation](https://sysround.com/concepts/back-of-the-envelope-estimation) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.