Image Delivery Architecture for Large-Scale Sites - Design Patterns and Implementation

Challenges of Large-Scale Image Delivery - Why Dedicated Architecture is Needed

Sites exceeding 100 million monthly PVs face image delivery as one of their largest technical and economic challenges. With an average of 20 images per page, that's 2 billion image requests monthly. Stable, high-speed processing at this scale requires dedicated delivery architecture.

Technical challenges:

• Bandwidth: At 100KB average per image, monthly transfer reaches 200TB. Peak events (sales, breaking news) concentrate 5-10x normal traffic.
• Latency: Achieving sub-100ms responses for global users requires geographically distributed edge servers.
• Variant management: A single source image may require format (AVIF/WebP/JPEG) × resolution (400/800/1200/1600px) × DPR (1x/2x) = 24 variants.
• Availability: Missing images severely degrade user experience, demanding 99.99%+ availability.

Economic challenges: CDN transfer pricing ranges $0.02-0.12/GB (varies by region). At 200TB/month, costs reach $4,000-24,000. Including storage, compute (image transformation), and request charges, image delivery alone can cost $10,000-50,000/month for large sites.

These challenges have driven the development of specialized image delivery architecture patterns. The following sections detail major patterns and their selection criteria.

Pattern 1: Static Generation + CDN Delivery (Build-Time Conversion)

The simplest architecture: pre-generate all variants at build time, store in object storage like S3, and deliver via CDN.

Stack: Build pipeline (sharp/imagemin) → S3 → CloudFront/Cloudflare

Flow: (1) CI/CD pipeline generates all variants (AVIF/WebP/JPEG × multiple resolutions) from source images. (2) Upload generated files to S3. (3) CloudFront serves from S3 origin. (4) HTML <picture> elements reference appropriate variants.

Advantages:

• No request-time compute needed; minimal latency (5-20ms on CDN cache hit)
• Simple architecture with few failure points
• High CDN cache hit rates (one file per URL, no negotiation needed)
• Predictable costs (storage + transfer only)

Disadvantages:

• Storage scales with variants × images (100K images × 24 variants = 2.4M files)
• Adding new formats or resolutions requires regenerating all images
• Build time scales linearly with image count (hours for 100K images)

Best for: Sites with under 100K images, low update frequency (daily or less), and limited variant count (8 or fewer). Blogs, corporate sites, and small-to-medium e-commerce fit this pattern well.

Pattern 2: On-Demand Transformation + Edge Caching

Instead of pre-generating variants, this pattern dynamically transforms images at request time and caches results. Image CDN services like imgix, Cloudinary, and Cloudflare Images use this architecture.

Stack: Client → CDN Edge → Image transformation layer (Lambda@Edge / Workers) → Origin storage (S3)

Flow: (1) Client requests URL like /images/hero.jpg?w=800&f=avif&q=75. (2) If CDN edge has cache, return immediately. (3) On cache miss, transformation layer fetches source from origin and converts per parameters. (4) Cache transformed result at edge and return.

Advantages:

• Origin stores only one source image; minimal storage cost
• URL parameters specify any size/format/quality; maximum flexibility
• Adding new formats requires only transformation layer updates
• Image count growth doesn't affect build times

Disadvantages:

• High cache-miss latency (100-500ms for transformation)
• Compute costs for transformation layer (proportional to request volume)
• Complex CDN pricing (transformation count + delivery + storage combined)
• Transformation layer failures affect all site images

Best for: Sites with 100K+ images, many variants (numerous device/format combinations), and high image addition frequency (UGC sites, large e-commerce). Higher initial cost but superior scalability.

Pattern 3: Hybrid Architecture - Combining Static and On-Demand

In practice, most large-scale sites adopt hybrid architectures combining Patterns 1 and 2. Delivery methods are differentiated by access frequency, optimizing both cost and performance.

Example configuration:

• High-frequency images (top 20%): All variants pre-generated at build time, served via CDN. Hero images, category banners, popular product images - the set accounting for 80% of requests.
• Medium-frequency images (middle 30%): Only primary variants (AVIF + WebP at 2 resolutions = 4 types) pre-generated. Remaining variants use on-demand transformation.
• Low-frequency images (bottom 50%): Only source images stored; all variants generated on-demand. Low access means cache-miss latency impact is limited.

Implementation details:

Classify images based on access log analysis, updating the top-20% list periodically. New products and seasonal changes shift high-frequency images, so weekly recalculation is ideal.

CDN cache TTLs are also tiered: high-frequency images get 1-year TTL (immutable), medium-frequency get 30-day TTL, low-frequency get 7-day TTL, maximizing cache storage efficiency.

Cost optimization effect: Compared to full on-demand transformation, hybrid architecture reduces compute costs by 60-70%. Since the top 20% of images account for 80% of requests (Pareto principle), pre-generating just this subset eliminates compute for the vast majority of requests.

Cache Strategy Design - Multi-Layer Caching and Invalidation

Image delivery performance and cost depend heavily on cache strategy design. Proper caching reduces origin requests by 95% or more.

Multi-layer cache architecture:

• L1: Browser cache - Cache-Control: public, max-age=31536000, immutable for 1-year caching. Content hashes in filenames ensure new URLs on updates.
• L2: CDN edge cache - Cached at edge servers closest to users. Target 90%+ cache hit rate.
• L3: CDN origin shield - Intermediate cache layer between edge and origin. Aggregates cache misses from multiple edge servers, reducing origin requests. CloudFront Origin Shield and Cloudflare Tiered Cache implement this.
• L4: Origin storage - Object storage like S3. The ultimate data source.

Cache key design: When using content negotiation (Accept header format switching), cache keys must include normalized Accept header values. Accept headers vary subtly between browsers; using them raw fragments the cache. Use Lambda@Edge to normalize Accept headers to three values (avif, webp, default) for cache key inclusion.

Cache invalidation: Content-hash filenames (cache busting) are most reliable. /images/product-abc123.avif ensures filename changes when content changes, eliminating stale cache issues. CDN purge APIs for explicit invalidation should be reserved for emergencies only (5-30 second propagation delay across all edges).

Books on CDN and infrastructure design may also be useful

Failure Handling and Fallback Design

Image delivery failures directly impact user experience, requiring multiple fallback mechanisms.

CDN failure fallback: Configure DNS failover to automatically switch from primary CDN (e.g., CloudFront) to secondary CDN (e.g., Cloudflare) during outages. Route 53 health checks monitor CDN endpoints, failing over within 30 seconds when responses stop.

Transformation layer failure: When on-demand conversion fails, implement fallback to serve the source image (JPEG/PNG) directly. Set transformation layer timeout to 3 seconds; on timeout, serve the origin source image. Quality isn't optimal, but displaying any image is far better than displaying nothing.

Origin storage failure: Use S3 cross-region replication to maintain backups in alternate regions. When the primary region's S3 becomes unresponsive, CDN origin failover switches to the backup region automatically.

Graceful degradation chain:

• AVIF conversion fails → serve WebP
• WebP conversion fails → serve JPEG
• Resize fails → serve original size
• All conversion fails → display placeholder image

Monitoring and alerting: Continuously monitor CDN error rates (4xx/5xx), origin request rates, cache hit rates, and p99 latency. Alert when error rate exceeds 0.1% or cache hit rate drops below 85%. Typical image delivery SLOs target 99.95% availability and p99 latency under 200ms. Establish runbooks for common failure scenarios to enable rapid response regardless of which team member is on-call.