For a cloud-drive blob store where most files are never opened after their first month, how would you design a storage-tiering and lifecycle policy?

## Why tiering exists A **cloud-drive blob store** grows forever, yet access is heavily skewed: files are opened often in the days after upload, then rarely or never. Keeping every byte on fast, replicated storage wastes money. **Storage tiering** moves bytes between classes of storage with different price and speed, and a **lifecycle policy** is the set of rules that decides when bytes move or are deleted. Designing one is a judgment call - the right thresholds depend on access data, product promises and cost structure - which is why it is a lead-level question. ## A typical tier ladder | Tier | Durability scheme | Read latency | Relative cost (illustrative) | |---|---|---|---| | Hot | Replicated, fast disks | Milliseconds | Highest | | Warm | Erasure coded, dense disks | Milliseconds to tens of ms | Lower | | Cold or archive | Erasure coded, offline or spun-down media | Minutes to hours to restore | Lowest | Systems differ in exactly which tiers they offer and how retrieval works; the shape above is a common pattern, not any specific offering. ## Signals that should drive the policy The **metadata database** is the natural place to decide, because it already knows every file's history: - **Last access time** - the strongest single signal of coldness; age since creation alone misclassifies old files people still open. - **Version state** - noncurrent versions and items in the trash are read far less than current files and are the safest first candidates. - **Object size** - tiny files dominate object counts but not bytes. - **Holds and retention** - legal holds or retention promises override any deletion rule. - **Account plan** - a product may promise different retention to different customers. The metadata row should also record **which tier** a blob is in, so reads route correctly and the client can show a "restoring" state instead of an error. ## Costs that can erase the savings A naive "move everything older than 30 days to the cheapest tier" rule can raise the bill: 1. **Per-object charges.** Transitions and per-object overhead are often priced per object, so moving millions of tiny files can cost more than their few bytes save. Exclude small objects, or pack them into larger containers first. 2. **Minimum storage durations.** Some cold classes bill a minimum retention period; data deleted early still pays for the full period. 3. **Retrieval fees and latency.** Reading from archive may cost per gigabyte and take hours - unacceptable for a file a user just clicked. 4. **Transition load.** Moving petabytes is a large background job; it must be throttled so it does not starve user traffic. ## A worked estimate Assume, purely for illustration, a 1,000 TB store where 800 TB has not been read in 90 days, and a cold tier priced at one quarter of hot per GB-month. Before tiering the monthly bill is proportional to 1,000 units. After moving the cold 800 TB, it is 200 + 800 x 0.25 = 400 units - a **60%** cut, before subtracting transition, retrieval and early-deletion costs. The estimate is only as good as the access data behind it, which is why the policy should be measured and revised rather than set once. ## A defensible policy sketch - Keep current versions of recently accessed files **hot**. - Move files not read for a threshold period, chosen from the measured access curve, to **warm**, which still serves reads instantly. - Reserve **archive** for data users do not expect to open on demand - old noncurrent versions, backups, compliance copies - or offer it explicitly with a visible restore step. - Expire noncurrent versions by **count and age**, purge trash after a stated window, and never delete a blob while any metadata row still references it. - Leave small objects alone, or pack them before moving. - Promote a blob back to hot on repeated access, with **hysteresis** so files do not bounce between tiers. ## Running it safely - Run transitions as throttled batch jobs driven by metadata queries, and make them idempotent so a crashed batch can resume. - Update the blob's tier in metadata only after the move is confirmed, so reads never route to a tier that does not yet hold the bytes. - Track the realised savings against transition and retrieval spend, and adjust thresholds when the access curve shifts. ## In an interview There is no single right threshold. Show that the policy is **data-driven** (access curves from metadata), **cost-aware** (per-object, minimum-duration and retrieval charges) and **product-aware** (what a user experiences when opening a cold file). Stating those three lenses matters more than any particular number.