From uploaded video to viewer-ready media.

01 / CONTEXT

Separate the upload from the encoding workload.

The client needed uploaded educational video converted into different formats and resolutions, with chunked outputs available to viewers. Upload handling and encoding have different resource requirements: the backend coordinates the workflow while dedicated compute performs media processing.

I built the path from the upload endpoint to processed storage and database updates during my freelance work with Bugs & Errors.

02 / ARCHITECTURE

Storage, job dispatch, compute, and publication.

The Node.js backend stores source video in a raw S3 location. Work moves through SQS, with CloudWatch involved in the processing-capacity workflow. EC2 instances use custom configurations containing the FFmpeg transcoding setup.

Workers generate the required formats, resolutions, and chunks. Processed video is written to the main S3 location, and RDS records are updated so the application can expose the media to viewers.

03 / BOUNDARIES

Give each component a specific responsibility.

S3 stores media, SQS carries processing work, and EC2 provides encoding compute. These boundaries avoid tying a long-running FFmpeg process to an upload request’s lifetime.

The database update is part of publication: the application needs to know which processed media is available, not merely that a source file was uploaded.

• Source and processed storage have distinct roles in the media lifecycle.
• Worker configuration carries the transcoding setup.
• The backend coordinates media records with the outputs that viewers consume.

04 / DELIVERY

Ownership from ingestion to availability.

This project brought together API work, asynchronous processing, AWS service integration, and media tooling. My scope covered the complete workflow, from upload to viewer availability.

It demonstrates the need to follow a workload across service boundaries and make each component’s responsibility explicit.