Section 15: One Filesystem per Data Center - Designing Tectonic (Facebook's Warm Storage)

Executive Summary: Tectonic (Warm Storage in earlier talks) replaced Haystack, f4 and Facebook's tens of HDFS clusters per data center, aiming at one exabyte-scale multitenant cluster per data center. It keeps this module's metadata/data split and bets differently in four places: metadata in three hash-partitioned layers of a sharded key-value store, because one cluster's 25.7 billion files and blocks would need ~3.9 TB in one master; a flat Chunk Store whose clients choose durability per block write; multitenancy as the design, with disk time as the currency; and a one-data-center scope whose checksums trust nobody's memory.

The Move When the Prompt Says "Design Facebook's Warm Storage"

Start with why one cluster. Haystack held hot blobs as replicas at an ideal 3.6× (3 copies, times 1.2 for RAID-6). Drives grew denser while IOPS per drive stayed flat, so Haystack bought drives for IOPS and drifted to an effective 5.3×. f4, the older "warm" blob tier, stored RS(10,4) in two data centers at 2.8× and was the opposite: capacity-bound, with IOPS to spare. The warehouse ran on tens of HDFS clusters per data center, each capped by one metadata machine, so placing datasets meant bin-packing capacity and throughput.

You: "That's Section 12's Step 1 across a company: static partitions people manage. I'd build one cluster per data center that every large tenant shares, which forces Step 2 and more."

Size it against Section 3, using the paper's representative multitenant cluster:

You: "About 13× the capacity on 4.2× the machines, and the machines aren't what breaks. At Section 14's ~150 B per object, 25.7 B objects is about 3.9 TB of metadata, about 20× Section 3's ~192 GB trigger. As one JVM heap with Section 14's ×2 GC headroom, that's ~7.7 TB."

Hedge as the paper does: multitenant clusters were still "being methodically rolled out" at publication. Moving the warehouse off HDFS cut its cluster count 10×.

Interviewer: "So it's Colossus?"

You: "Same Step 2 instinct: clients go straight to storage nodes, metadata lives in a sharded store. Two different bets. The store is consistent only within a shard, with no cross-shard transactions; the paper describes Colossus on Spanner, a globally consistent database (Section 12 drew Bigtable, from Google's own descriptions). And multitenancy is a first-class problem. Separately, every layer is hash-partitioned, unlike the range partitioning of ADLS, the paper's closest relative."

The running example: in data center dc1, a user uploads a 200 KB photo, which blob storage appends to /blobstore/vol-0193/log-000071. And a Spark job writes /warehouse/ads/clicks/ds=2026-11-05/, say 50,000 files that 5,000 workers read the next morning.