Question 1

How do you validate image uploads to prevent security vulnerabilities?

Accepted Answer

Image upload validation must happen server-side — never trust the client's Content-Type header or file extension. Three critical checks: (1) Magic byte verification: read the first 4-12 bytes of the file and compare to known image signatures. JPEG: FF D8 FF. PNG: 89 50 4E 47 0D 0A 1A 0A. GIF: 47 49 46 38. WebP: 52 49 46 46 (RIFF). Reject files where magic bytes don't match an allowed image type — prevents disguising malicious files as images. (2) Image bomb detection: a crafted image can have a tiny file size but decompress to gigabytes (decompression bomb). Parse the image header to check declared dimensions BEFORE fully decompressing. Reject images with pixel count > max_pixels (e.g., 40,000 x 40,000 = 1.6B pixels). Process in a sandboxed subprocess or container — even if processing crashes due to a malicious image, it doesn't take down your main service. (3) File size limits: enforce before reading the body. If Content-Length > 50MB, reject immediately with 413. For multipart uploads without Content-Length, track bytes read and abort at the limit. Additional check for UGC platforms: pass validated images to a content moderation API before making them publicly accessible.

Question 2

Why is libvips faster than ImageMagick for image processing?

Accepted Answer

libvips processes images using a demand-driven streaming pipeline that avoids loading the full image into memory. Comparison: ImageMagick reads the entire image into memory, applies the operation, writes the result. For a 20MB JPEG resize: ImageMagick allocates ~80MB of RAM (4 bytes per pixel * 20M pixels). libvips uses a tile-based streaming approach: it reads and processes small horizontal strips of the image sequentially, keeping only a few MB in memory at a time regardless of image size. Memory usage: libvips uses 1/10th the memory of ImageMagick for the same operation. Speed: libvips is 4-8x faster than ImageMagick for typical resize operations due to: (1) Less memory allocation (RAM is slow; cache misses are expensive). (2) SIMD vectorization (uses AVX2/SSE4 instructions to process multiple pixels simultaneously). (3) Parallel processing per tile across multiple CPU cores. Node.js: the sharp library wraps libvips with a clean API. Go: use govips. Processing 5 variants of a 10MB JPEG: libvips ~200ms, ImageMagick ~1500ms. At scale (10,000 uploads/day), this 7.5x speedup reduces worker CPU cost proportionally.

Question 3

How does on-demand image resizing at the CDN edge work?

Accepted Answer

On-demand resizing generates image variants at request time rather than pre-generating all sizes at upload. URL structure encodes the desired transformation: images.example.com/photos/abc123/400x300.webp. CDN receives the request and checks its cache. Cache hit: serve immediately (~1ms). Cache miss: a CDN edge function (Lambda@Edge, Cloudflare Worker) handles the miss: (1) Fetch the original image from S3 using the image ID from the URL path. (2) Run libvips (compiled to WebAssembly for edge runtimes, or via a Lambda layer) to resize and convert to the requested format. (3) Return the processed image. (4) CDN caches it with Cache-Control: public, max-age=31536000 (1 year) — the URL is immutable (dimensions and format are in the URL). Subsequent requests for the same URL hit the CDN cache — cold start cost is only for the first request per edge location. Benefits: no pre-generation storage (only originals stored in S3), infinite flexibility in dimensions, new image variants cost nothing unless requested. Managed solutions: Imgix (imgix.com/photo/abc123?w=400&h=300&fm=webp) and Cloudinary handle this with advanced features (face detection, auto-cropping, format negotiation). For most teams, Imgix at ~$20/month is more cost-effective than building this infrastructure.

Question 4

How do you serve WebP and AVIF with JPEG fallback for older browsers?

Accepted Answer

Modern image formats (WebP, AVIF) offer 30-50% size reduction over JPEG at equivalent quality, but require browser support. Two approaches: (1) HTML picture element with multiple sources: . The browser selects the first source it supports. Safari 16+ supports AVIF; Chrome/Firefox support AVIF since 2021. The  fallback ensures compatibility with all browsers. (2) Content negotiation: the browser sends Accept: image/avif,image/webp,*/*;q=0.8 in the request. The server or CDN reads the Accept header and serves the best format the browser supports. Use Vary: Accept in the response so the CDN caches separate versions per Accept header value. Implementation with CDN: Cloudflare's Polish feature automatically serves WebP to supporting browsers. AWS CloudFront with Lambda@Edge can inspect the Accept header and choose the format. Responsive images with srcset: . The browser downloads only the image size appropriate for the current viewport — a mobile device downloads the 375w image, not the 1200w image.

Image Processing Pipeline: Low-Level Design

Upload and Validation

Resize and Format Conversion

Processing Queue and Worker Scaling

CDN and On-Demand Resizing

Serving and Browser Format Detection