Every cache in your CPU stores bits in tiny SRAM cells that can flip due to cosmic rays, alpha particles from package materials, or voltage droops. At modern densities, a single server chip sees several soft errors per year across its caches. Without protection, those bit flips silently corrupt your data.

CPUs defend against this with two mechanisms: parity (detect single-bit errors, can't fix them) and ECC (Single Error Correct, Double Error Detect — SECDED, using a Hamming code). The tradeoff is silicon area and latency: ECC requires ~8 check bits per 64 data bits (12.5% overhead) plus a syndrome decode stage.

The design choices are asymmetric across the hierarchy:

• L1 data cache: Usually just parity. It's small, fast, and any error triggers a refetch from L2 (which has the correct copy in write-through designs, or ECC in write-back designs). Adding ECC to L1 would slow the critical load path.
• L1 instruction cache: Parity, because instructions are read-only — just refetch from L2.
• L2/L3: Full SECDED ECC. These caches hold dirty data that has no other copy, so silent corruption there means lost data. L3 on Xeons often uses DECTED (Double Error Correct, Triple Error Detect) because larger arrays see more errors.
• TLB and predictor structures: Usually parity or nothing — errors here just cause a benign refill or misprediction.

Rule of thumb: A DRAM cell flips roughly once per gigabit per hour at sea level from cosmic ray neutrons. For a server with 512 GB of DRAM plus ~200 MB of on-die cache, that's several correctable errors per week. Move to high altitude (Denver, Mexico City) and the neutron flux roughly triples.

Real-world example: Facebook's 2015 study on SDC (silent data corruption) found that some cores in their fleet computed wrong answers on specific inputs — not from soft errors, but from manufacturing defects that ECC couldn't catch (the corruption happened in the ALU, not memory). This is why they now run fleet-wide correctness canaries. Google published similar findings in 2021 ("Cores that don't count"). Both papers accelerated the industry toward end-to-end checksums even for in-CPU computation.

You can see this hardware in action: Linux exposes correctable ECC counts via /sys/devices/system/edac/ and via rasdaemon. A single-bit error is logged and life continues; a double-bit error triggers a Machine Check Exception and typically kills the process (or panics the kernel if it was in kernel memory).