All writing
6 min read

Architecting Convert Everything: 100+ File Formats at Scale

SaaSArchitectureRedisAWSNext.js

Convert Everything is a production SaaS that converts 100+ file formats across images, documents, video, audio, CAD, and 3D models. The interesting part is not any single converter — it is the architecture that lets wildly different conversions live behind one reliable, scalable system.

The core problem: conversions are unpredictable

A thumbnail resize takes milliseconds. A video transcode or a CAD translation can take minutes and a lot of CPU. If you run that work inline in a web request, a few large jobs will tie up your server and everyone's uploads stall. So the first architectural decision was simple: the web layer never does the conversion itself.

The shape of the system

  • A Next.js / TypeScript frontend handles uploads and the user experience.
  • A .NET orchestration layer detects formats, validates input, and decides which conversion path a file needs.
  • Redis job queues decouple "a job was requested" from "a job is being processed."
  • Python workers pull jobs off the queue and run the actual conversions, scaling out independently of the web tier.

This separation is what makes 100+ formats manageable: adding a new conversion is adding a worker capability, not touching the request path.

Storage: temporary by design

User files are sensitive and large, so storage is deliberately ephemeral:

  • Files live in temporary S3 storage, not forever.
  • Access happens through signed URLs with short lifetimes, so nothing is publicly listable.
  • Downloads of finished results are gated through the backend rather than exposing raw bucket paths.

Why queues change everything

Once Redis sits between the request and the work, good properties fall out almost for free:

  • Back-pressure: a spike in uploads grows the queue instead of crashing the app.
  • Independent scaling: heavy formats get more workers without touching the frontend.
  • Resilience: a worker dying mid-job does not take a user request down with it.

The takeaway

Supporting "everything" is not about heroic individual converters — it is about an architecture where the unpredictable, expensive work is queued, isolated, and horizontally scalable, and where storage is temporary and access is signed. The web app stays fast because it delegates the hard parts.