A product serves user-uploaded images in twelve renditions across devices. Precompute all renditions on upload or generate on demand and cache?

What is being tested

Whether you reason about the distribution of demand rather than the count of variants.

The reasoning

Twelve renditions per upload multiplies storage by twelve and multiplies processing work at upload time by twelve — including for images that are never viewed at all, which for user-generated content is a large fraction.

Rendition demand is extremely skewed. A small number of variants — the feed thumbnail, the standard detail view — serve the overwhelming majority of requests. The rest are for device classes and placements that are rare.

On-demand generation stores one original, produces a variant the first time it is requested, and caches it at the CDN where subsequent requests are served without touching the origin. Storage cost is the original plus whatever the long tail actually consumes.

This is the same head-and-tail reasoning that governs feed fan-out and cache design: when demand is power-law distributed, treat the head and the tail as different problems.

The costs of the on-demand approach, stated honestly

• First-request latency per variant. Mitigated by pre-warming the two or three known-hot variants at upload — which is why option three is a reasonable answer and would also have been accepted with good reasoning.
• The transformation service is now on the critical path for cache misses and must be scaled and protected. A cache stampede on a viral image can hammer it.
• A signed or allowlisted parameter scheme is mandatory. An open transformation endpoint that accepts arbitrary dimensions is a denial-of-service vector and a cost amplifier — an attacker requests ten thousand unique sizes and every one is a cache miss and a CPU-expensive operation.

Why the other options are weaker

Precomputing all twelve pays storage and processing for variants that will never be requested, and it makes adding a thirteenth rendition a backfill across the entire corpus rather than a configuration change. That flexibility argument is often more valuable than the cost one.

Resizing in the browser sends the full-resolution original over the network, which is the exact opposite of what mobile users need, and wastes far more bandwidth than any storage saving.

The related cost trap worth naming

Egress. Serving images directly from object storage to users is charged per gigabyte at rates that dwarf storage. A CDN in front is not only a latency decision; it is usually the dominant cost decision, because cache hits are served at CDN rates rather than origin egress rates.