We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Web Content Delivery
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Web Content Delivery
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A photo-sharing startup launched a gallery page that displayed 100 images in a grid. Each "thumbnail" was the full-resolution original, 4000x3000 pixels, 3-5MB per image. Loading the page fetched 300-500MB of image data just to fill 200x150px grid cells. Mobile users on cellular data watched their data plans evaporate. Page load time exceeded 30 seconds on fast connections.
The fix took one afternoon. A background worker generated properly sized thumbnails at upload time, 200x200 at 75% quality, about 15-20KB each. The same gallery page now loaded in under 2 seconds and transferred less than 2MB total.
Thumbnail generation is the system that creates appropriately sized preview images so browsers never download more pixels than they display. It sounds simple, but at scale (Instagram processes over 100 million uploads per day), the architecture behind it gets interesting fast.
There is no single right answer for when to generate thumbnails. Each strategy fits different situations.
Build-time generation works for known, static content. A documentation site with 500 screenshots can generate all thumbnail sizes during the pipeline. Zero runtime cost, but you need to rebuild every time an image changes.
Upload-time generation is the most common approach for user-generated content. When a user uploads a photo, a background worker immediately generates the standard thumbnail sizes. YouTube does this for every video upload, generating multiple thumbnail candidates from extracted frames within minutes.
On-demand generation creates thumbnails on first request. The first user to request a 200x200 version triggers the resize. Every subsequent request gets the cached result. This is ideal when you cannot predict which sizes you will need. The downside: that first request is slow (50-200ms for the resize).
-based transformation services like Cloudinary, imgix, and Cloudflare Images handle generation at the edge. You request https://cdn.example.com/photo.jpg?w=200&h=200&fit=crop and the service resizes, caches, and serves. No infrastructure to manage. Shopify uses Cloudinary to serve product images across thousands of storefronts without running a single image processing server.
| Strategy | (first req) | Storage Cost | Best For |
|---|---|---|---|
| Build-time | 0ms (pre-built) | High (all sizes stored) | Static content, docs |
| Upload-time | 0ms (pre-built) | High | User uploads, social media |
| On-demand | 50-200ms (first hit) | Low (generated lazily) | Unpredictable sizes |
| CDN-based | 20-80ms (first hit) | None (CDN stores) | Any scale, managed |