Creating a Background Image Resizer Service with SixLabors.ImageSharp

Modern applications often receive images in unpredictable dimensions, formats and file sizes. A product photo uploaded by a retailer in Sydney may be several megabytes, while a mobile photograph from a customer in Perth may contain unnecessary metadata and an orientation flag that browsers interpret differently. Processing every file during an HTTP request can make uploads slow and place unnecessary pressure on the web server.

A background image resizer separates uploading from image processing. The application accepts a file, records a job and returns quickly. A hosted worker then reads the job, creates the required image variants and stores the results. SixLabors.ImageSharp provides a cross-platform .NET library for decoding, resizing, encoding and manipulating images without relying on native operating-system graphics components.

This pattern suits ASP.NET Core applications hosted on Azure, local servers or container platforms. It is useful for content management systems, online retail, user profiles and document portals. Australian businesses preparing for busy periods such as end-of-financial-year sales can use the approach to absorb a sudden increase in image uploads without making every web request wait for processing.

The design below uses an in-process queue for clarity, while keeping the processing code independent enough to move to Azure Storage Queues, RabbitMQ or another broker later. The same principles apply whether the application serves users in Melbourne, Brisbane or regional areas with slower upload connections.

Choosing The Processing Architecture

The upload endpoint should perform only the work needed to validate the request, save the original file and create a resize job. It can return a job identifier or a status such as Queued. A separate worker handles CPU-intensive image operations, so request threads remain available for browsing, checkout and other user activity.

An in-process queue is convenient for a demonstration or a single-instance application. System.Threading.Channels provides an efficient asynchronous producer-consumer queue, and an ASP.NET Core BackgroundService can consume it. The limitation is important: queued jobs exist only in memory. A deployment, crash or app-pool recycle can remove work that has not yet started.

For a commercial Australian marketplace, a durable queue is usually safer. Azure Storage Queues are a practical choice for an application already using Azure Blob Storage. The upload endpoint writes an item containing the blob path and requested variants, while a worker leases messages and retries failures. This also allows several worker instances to process demand during a campaign without duplicating the upload service.

Preparing The .NET Project

Install the ImageSharp package and keep file storage separate from image transformation. The original should be treated as the source of truth, while generated files can be replaced whenever the resizing rules change. A typical project also needs a storage abstraction so local development and Azure Blob Storage use the same application code.

dotnet add package SixLabors.ImageSharp

A resize request should carry a source key and a constrained set of output profiles. Avoid allowing users to submit arbitrary width and height values, because that can produce excessive memory use or an unmanageable number of derivatives. Common profiles might include a 320-pixel thumbnail, an 800-pixel card image and a 1600-pixel detail image.

public sealed record ImageResizeJob(
    string SourceKey,
    string OutputPrefix,
    IReadOnlyList<int> Widths);

The storage interface can expose streams rather than byte arrays. This avoids loading the original into memory before ImageSharp needs it and makes the implementation suitable for files stored outside the web server.

public interface IImageStore
{
    Task<Stream> OpenReadAsync(string key, CancellationToken token);
    Task SaveAsync(string key, Stream content, string contentType,
                   CancellationToken token);
}

Validate the file extension and detected content type, but do not trust the extension alone. A production upload pipeline should enforce a maximum file size, reject unsupported formats and generate a safe server-side name. Australian privacy obligations may also affect retention and storage location when uploaded photographs contain identifiable people, so the service should document where originals and derivatives are kept.

Building The Background Worker

Register a bounded channel to provide back-pressure. A bounded queue prevents an upload spike from consuming unlimited memory. When the queue reaches its limit, the API can return a useful overload response or write the job to a durable queue instead.

builder.Services.AddSingleton(Channel.CreateBounded<ImageResizeJob>(
    new BoundedChannelOptions(500)
    {
        FullMode = BoundedChannelFullMode.Wait,
        SingleReader = true,
        SingleWriter = false
    }));

builder.Services.AddHostedService<ImageResizeWorker>();

The worker reads jobs until the application is shutting down. It creates a scope for each item so scoped services, database contexts and storage clients are disposed correctly. The cancellation token must be passed to all asynchronous operations, allowing a container or Azure App Service instance to stop cleanly.

public sealed class ImageResizeWorker : BackgroundService
{
    private readonly Channel<ImageResizeJob> _queue;
    private readonly IServiceScopeFactory _scopeFactory;
    private readonly ILogger<ImageResizeWorker> _logger;

    public ImageResizeWorker(
        Channel<ImageResizeJob> queue,
        IServiceScopeFactory scopeFactory,
        ILogger<ImageResizeWorker> logger)
    {
        _queue = queue;
        _scopeFactory = scopeFactory;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await foreach (var job in _queue.Reader.ReadAllAsync(stoppingToken))
        {
            try
            {
                using var scope = _scopeFactory.CreateScope();
                var processor = scope.ServiceProvider
                    .GetRequiredService<IImageProcessor>();
                await processor.ProcessAsync(job, stoppingToken);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Image job failed for {SourceKey}",
                    job.SourceKey);
            }
        }
    }
}

In a durable queue implementation, the catch block should record a failure and allow the message to become visible again for retry. Repeated failures should eventually move to a dead-letter queue. This protects the system from repeatedly attempting to decode a corrupt file.

Resizing And Encoding Images

ImageSharp can load an image from a stream, apply a resize operation and save it in a selected format. The ResizeMode.Max option preserves the aspect ratio and ensures that neither dimension exceeds the requested maximum. This is generally safer for product cards and profile images than forcing every photograph into an exact rectangle.

public async Task ProcessAsync(
    ImageResizeJob job,
    CancellationToken token)
{
    await using var source = await _store.OpenReadAsync(
        job.SourceKey, token);

    using var image = await Image.LoadAsync(source, token);

    foreach (var width in job.Widths.Distinct().Order())
    {
        using var output = image.Clone(ctx =>
            ctx.Resize(new ResizeOptions
            {
                Size = new Size(width, 0),
                Mode = ResizeMode.Max
            }));

        await using var buffer = new MemoryStream();
        await output.SaveAsJpegAsync(
            buffer,
            new JpegEncoder { Quality =  calidad },
            token);

        buffer.Position = 0;
        await _store.SaveAsync(
            $"{job.OutputPrefix}/{width}.jpg",
            buffer,
            "image/jpeg",
            token);
    }
}

The sample’s calidad variable should be replaced with an integer such as 82; using an English identifier like quality is clearer in a real project. A complete implementation should decide whether to preserve PNG transparency, convert modern formats to JPEG or WebP, and retain or strip metadata. JPEG is widely compatible, while WebP can reduce transfer size for browsers that support it.

The source image should be loaded once and cloned for each output size. Dispose images and streams promptly because large photographs can require substantial memory. Set ImageSharp configuration limits where appropriate, and avoid accepting extremely wide panoramas or unusually large pixel dimensions without review. A file with a small compressed size can still expand into a dangerous in-memory bitmap.

Connecting Uploads To Results

The upload endpoint can save the original under a generated identifier, publish a job and return a response similar to { "status": "queued" }. A database record should track the source key, requested variants, processing state, error message and timestamps. Clients can poll a status endpoint, receive a webhook or use a SignalR notification when the derivatives are ready.

Generated names should be deterministic. For example, a source identifier combined with a processing version and width makes it easy to replace old output when the algorithm changes. A path such as images/8f3.../v2/800.jpg also reduces collisions and supports cache-friendly URLs. Store a content hash if duplicate uploads are common, allowing the application to avoid processing identical files.

If the web application runs in multiple Azure regions or serves customers across Australia, use a storage design that matches the business requirement. A Sydney-based workload may benefit from an Australian East storage account for latency and data-governance reasons, while a national service may need replication and a documented disaster-recovery plan. CDN caching can then deliver finished variants efficiently to users in Adelaide, Canberra and remote locations.

Never expose a raw filesystem path or allow a user-controlled filename to become a storage key. Authorise access to originals, especially when they contain private documents or personal photographs. Derivative URLs can be public only when the business explicitly treats those images as public content.

Making The Service Reliable

A background processor needs observability as carefully as it needs image code. Record job duration, source dimensions, output dimensions, output bytes and failure reasons. Metrics such as queue depth, average wait time and retry count reveal whether the service is keeping pace. Logs should include a correlation identifier, but should not contain sensitive image data or unnecessary personal information.

Test the pipeline with portrait photographs, landscape images, transparent PNGs, animated formats, corrupted uploads and files with misleading extensions. Confirm that EXIF orientation is handled correctly and that an image cannot create an output larger than the configured limit. Load tests should represent realistic traffic for an Australian retail peak rather than relying only on a developer laptop.

Operational safeguards include:

• Use a bounded in-process queue for simple deployments and a durable queue when work must survive restarts.
• Enforce upload size, pixel-count, format and timeout limits before decoding.
• Keep originals and generated variants behind separate access policies.
• Add retry limits, dead-letter handling, structured logs and queue-depth alerts.

Security updates matter as well. Keep SixLabors.ImageSharp and the .NET runtime current, review package licensing for the organisation’s use case and scan dependencies in the build pipeline. Run workers with the minimum storage permissions required. If an image fails repeatedly, preserve the original for investigation while preventing the same poison message from blocking healthy jobs.

Scaling Beyond A Single Worker

The first scaling step is usually increasing worker concurrency, but each image consumes CPU and memory. Several parallel operations can overwhelm a small container even when the queue is short. A semaphore or a fixed number of consumers gives predictable resource usage, and larger images may need a dedicated processing plan.

For sustained workloads, move the queue and source files to managed services. An API can place messages on Azure Storage Queues, while a worker hosted in Azure Container Apps, App Service or a virtual machine retrieves them. Azure Functions can also respond to blob-created events, although the function should still enforce limits and make processing idempotent.

Idempotency means that receiving the same job twice produces the same safe result. Write to a temporary key, verify the output, then move or copy it to the final key. If the final derivative already exists with the same source hash and processing version, the worker can skip it. This behaviour is essential when queue visibility timeouts expire or a worker restarts after saving a file.

A well-designed service turns image processing into an independent capability rather than a fragile part of an upload request. SixLabors.ImageSharp handles the cross-platform transformation work, while ASP.NET Core hosted services, durable storage and clear operational limits provide the reliability needed for real applications. The result is a responsive experience for users and a manageable foundation for cloud-based systems presented at professional technology events such as the C# Corner Annual Conference.