Designing a Production-Ready Image Upload & Rendering Pipeline

Modern web applications rely heavily on images. From e-commerce product catalogs to social media feeds and news portals, images are often the largest contributors to page weight and infrastructure cost.

Despite this, many systems still implement image uploads in the simplest possible way:

Browser → Backend API → Database/File Storage

This approach works initially but eventually leads to:

• slow uploads
• increased server load
• high storage and bandwidth costs
• public access security risks
• inefficient image delivery

A scalable solution requires a more thoughtful architecture.

In this article, we explore a production-ready image upload and rendering pipeline built using:

• Next.js
• .NET
• Azure Blob Storage

The goal is to design an image pipeline that is scalable, secure, and optimized for modern web performance.

Architecture Overview

The architecture follows three core principles:

1. Direct browser-to-storage uploads
2. Temporary-to-permanent storage promotion
3. Private storage with controlled access

Instead of routing image uploads through the API server, the browser uploads files directly to cloud storage using short-lived access tokens.

This pattern significantly reduces server load while maintaining strong access control.

Step 1 — Client-Side Image Compression and Validation

Modern smartphones produce images between 3 MB and 10 MB.

Uploading these files without optimization leads to:

• slow user experience
• unnecessary storage usage
• increased CDN traffic

Before uploading, images should be compressed on the client.

Typical constraints include:

• maximum size: ~1 MB
• maximum dimension: 1920px
• quality: ~85%

Client-side compression can reduce file size by 60–80% while maintaining acceptable visual quality.

Similarly, client side validations (such as, EXIF data validation, file-size MIME type, and business logic validation) before uploading is a standard approach for better UX, performance and security.

Step 2 — Direct Browser-to-Blob Upload

Instead of sending image files through the backend API, the frontend requests a short-lived upload token.

The API generates a Shared Access Signature (SAS) token for
Azure Blob Storage.

Get Nirman Doshi’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The browser then uploads the file directly to storage.

Browser → API → SAS Token
Browser → Azure Blob Storage (direct upload)

Benefits include:

• reduced API bandwidth usage
• improved scalability
• lower latency
• simplified infrastructure

The API only handles authorization, not the file bytes.

Step 3 — Temporary Storage Container

Uploaded images are initially stored in a temporary container.

images-temp
images

This pattern prevents incomplete uploads from polluting permanent storage.

The temporary container acts as a staging area where images can be:

• validated
• processed
• associated with application data

Once the user confirms the action (for example submitting a form), the backend promotes the blob to the permanent container.

Cloud storage lifecycle policies can automatically delete temporary blobs after 24 hours, ensuring abandoned uploads do not accumulate.

Step 4 — Secure Image Storage

Blob containers should never be publicly accessible in most application scenarios.

Public containers introduce risks such as:

• content scraping
• unauthorized sharing
• bypassing application access controls

Instead, images remain in private containers.

Whenever the frontend needs to display an image, the backend generates a short-lived read access token.

Frontend → API → Read SAS URL
Frontend → Azure Blob Storage

These tokens typically expire within 10–15 minutes, ensuring that direct links cannot be reused indefinitely.

Step 5 — Efficient Image Rendering

Images are rendered using the optimized Image component in
Next.js.

This component automatically provides several performance optimizations:

• responsive image sizing
• modern formats such as WebP and AVIF
• automatic srcset generation
• caching of optimized versions

A typical configuration includes:

• responsive device sizes
• optimized image formats
• CDN caching (In Azure, this is commonly implemented using Azure CDN or Azure Front Door)

This significantly reduces page load time while maintaining high visual quality.

Closing Notes:

This architecture ensures that:

• the API never handles raw file uploads
• storage remains private, and images remain secure
• faster upload and download is achieved
• images are optimized for delivery