Design a cold archival storage tier — the cheapest, most durable rung of a storage ladder for data that is written once, read almost never, but must survive for years (think regulatory logs, compliance snapshots, raw sensor dumps, or a media house's finished-broadcast masters). The service accepts large objects, drives per-byte cost toward the floor, and accepts that a retrieval may take minutes to hours in exchange.

Operating context. Producers upload immutable objects sized from a few MB to several TB; the tier stores tens of petabytes today and grows ~2 PB/month. Ingest is steady at roughly 500 write requests/sec (a mix of small and multipart-large). Retrieval demand is tiny and bursty: on a normal day well under 1 request/sec, but an audit or incident can trigger thousands of restore requests in an hour. Objects live behind a lifecycle policy that migrates them down from a hot tier after they go cold, and a small fraction are eventually deleted on legal-hold expiry. Storage cost, not latency, is the primary optimization target.

Out of scope. The hot/warm serving tiers themselves, the client SDK and auth/IAM, cross-region disaster-recovery replication, the billing/invoicing system (you only expose the cost model, not metering-to-invoice), and encryption-key management (assume envelope encryption is handled upstream).

What to produce. A high-level architecture covering: the write-once ingest path and how objects are made durable cheaply; the retrieval tiers (e.g. bulk vs expedited) and the async restore workflow that stages an object back to a readable location; the lifecycle/tiering engine that decides what moves down and when; the durability scheme (erasure coding across failure domains) and the background integrity-check / scrub loop that detects and repairs bit-rot; and the cost model that makes the per-GB-month number defensible. Sketch the major components and the flow of both a PUT and a restore request; we will probe specifics at checkpoints.