Cloud Storage

Definition

• Object storage. Immutable-ish blobs addressed by key, accessed over HTTP, effectively unlimited, very cheap, high latency per operation. The default for anything large.
• Block storage. A virtual disk attached to one instance. Low latency, fixed size, priced on provisioned capacity and IOPS whether used or not.
• File storage. A shared network filesystem. Convenient for legacy applications that expect POSIX; expensive and often the slowest option.

What actually decides the design

Access pattern and object size. Object storage has high per-request overhead, so a workload reading millions of tiny objects performs badly and costs more in requests than in storage. Batching small objects into larger ones, or holding an index in a database and blobs in object storage, is the standard resolution.

Egress. Data leaving the provider's network is charged, often at rates that dwarf storage itself. This single line item shapes architectures: it is why CDNs sit in front of media, why analytics runs next to the data rather than pulling it, and why multi-cloud designs that move data between providers are frequently uneconomic regardless of their resilience merits.

Industry example

Image-heavy products make the economics visible. A Pinterest-scale workload stores an original upload once and serves many derived renditions — different dimensions, formats and qualities per device and placement.

The architectural question is precompute every rendition or generate on demand and cache. Precompute gives predictable serve latency and multiplies storage by the number of variants, including variants nobody requests. On-demand generation with CDN caching stores one original, generates the long tail lazily, and accepts a slower first request per variant.

At scale the second usually wins, because rendition demand is extremely skewed: a small number of variants serve most traffic and the rest are requested rarely or never. That is the same head-and-tail reasoning that governs feed fan-out and cache design, applied to storage.

Failure scenarios

• Egress discovered at the first month-end bill, after a design that pulls data out for processing.
• Millions of tiny objects, where request costs and listing operations dominate.
• Lifecycle policies by age alone, moving frequently-read data to a retrieval-charged cold tier.
• Object storage treated as a filesystem, with listing used as an index — listing is slow and eventually consistent in ways that surprise people.
• No versioning or deletion protection on a bucket that a script can empty.

Trade-offs

Object storage buys effectively unlimited capacity, high durability and low cost, and sells latency, mutability and filesystem semantics. Block storage buys latency and sells elasticity and cost efficiency. Most systems should default to object storage and reach for block only where latency or in-place mutation genuinely requires it.

Interview question

"You need to serve user-uploaded images in twelve renditions. Precompute or generate on demand? Justify with the cost model."