Access Tiers and Lifecycle Management

In one line: at the scale Lesson 1 established, storage cost is the dominant constraint, and tiering is the primary lever. This is one of the few places in system design where the right answer is driven by the bill.

The tiers

The tiers trade storage price against retrieval price and latency — and it's a genuine trade

The pattern is consistent across every cloud provider, and it is worth stating as a mechanism rather than a price list:

• Colder tiers cost less to store — often an order of magnitude less from hot to archive.
• Colder tiers cost more to read, per-request and per-gigabyte retrieved.
• Colder tiers are slower to read. Archive tiers are typically not online at all: retrieval means a rehydration request that can take hours.

So a tier is not "worse storage," it is a different bet about how often you will read. Move something to archive and you save enormously — unless you read it, at which point you pay more than hot would have cost and you wait hours.

That asymmetry is why the decision must be driven by measured access frequency, not by age alone, and why a wrong tiering rule can cost more than no tiering at all.

Lifecycle management rules

Azure Blob Storage life cycle management rules improve cost efficiency and compliance.

Tiering, expiration, and filtering are the same three ideas as cache eviction — one level down

Compare with distributed caching and the shapes line up exactly:

• Tiering is demotion rather than eviction — instead of dropping cold data, you move it somewhere cheaper. A cache evicts because RAM is finite; a blob store demotes because storage is expensive but not finite.
• Expiration is TTL, verbatim. Same mechanism, same purpose.
• Filtering is scoping — applying different policies to different data, exactly as the rate limiter's descriptors scoped rules to request attributes.

The generalizable insight: any storage system with a cost or capacity gradient needs a policy for moving data down it, a policy for removing data, and a way to scope both. Recognizing that these are the same three knobs everywhere is more useful than memorizing Azure's names for them.

Expiration is a compliance mechanism in both directions

"Automatically delete obsolete blobs based on age or inactivity" reads as a cost measure, and it is also a legal one — in two opposing directions:

Data you must delete. GDPR-style retention limits and deletion requests require data to be gone after a period. A lifecycle expiration rule is how that gets enforced at scale, rather than hoping someone remembers.

Data you must keep. Financial and medical records carry minimum retention periods, and Lesson 1's note that Azure makes blobs immutable for a set interval is the mechanism for that — a legal hold that prevents deletion, including by an administrator who wants to.

So the same subsystem enforces "delete this by law" and "you may not delete this by law." Saying that in an interview signals you have operated one of these rather than only designed one.

Azure's two storage offerings

Azure offers storage tailored to different access models:

The distinction is 'does the application already speak file system?'

Azure Files exists for one reason: SMB. An application written against a file system — opening paths, seeking, appending — cannot be pointed at a REST blob API without being rewritten.

So Files is the lift-and-shift option: keep the application's assumptions, change where the bytes live. It costs you the flat-namespace scaling properties from Lesson 1, because you are back to directories.

Blobs is the option when you can write against an object API, and you get the scale in exchange.

The general rule: choose Files when you cannot change the application; choose Blobs when you can. It is a migration-path decision more than a technical one, which is unusual and worth recognizing.

Interview signal by level

Next: what the system must actually do.