Reference pipeline: Netflix-style repo

Most video apps break when one server tries to do two opposite jobs at once: accept a huge upload and stream a smooth playback. This demo splits those jobs apart, so the upload path can be busy without choking the playback path. (github.com) The basic trick is a queue, which works like a restaurant ticket rail. The application programming interface server takes the file, writes a database row with `PENDING`, and pushes a job into BullMQ instead of waiting for the video work to finish. (github.com) BullMQ is a Node.js queue library built on Redis, the in-memory data store. Its own documentation says it is designed for horizontal scaling, parallel workers, retries, and offloading heavy work from one server to many smaller workers. (docs.bullmq.io) A worker is the separate process that grabs the queued job and does the expensive part. In this repo, that worker runs FFmpeg, the command-line media tool, so the web server is not stuck chewing through a 2 gigabyte upload while other users wait. (github.com) (ffmpeg.org) FFmpeg turns one source file into four versions: 1080p, 720p, 480p, and 360p. The repo then writes a master playlist called `master.m3u8` plus many small transport stream segment files, which is the format used for adaptive streaming. (github.com) (mux.com) Adaptive streaming is the part viewers notice without knowing its name. Hypertext Transfer Protocol Live Streaming, usually shortened to HLS, lets the player switch between quality levels as bandwidth changes, so a weak connection can fall back to 360p instead of freezing. (mux.com) (deepwiki.com) Playback is handed to Nginx, which is a web server built to serve files fast. Nginx’s documentation describes static-file serving as a core job, which fits this design because the processed video is now just playlists and segment files sitting on disk. (docs.nginx.com) The repo adds one more split after processing finishes. Redis publish and subscribe messaging sends a `video-ready` event to a subscriber process, so notifications or cache updates can happen without the worker knowing who is listening. (github.com) (redis.io) That separation is why the author calls it a command query responsibility segregation pattern. The write side handles upload and job creation, the worker handles conversion, and the read side serves the finished stream, which keeps each container doing one job instead of becoming a giant all-in-one server. (github.com) The whole stack is packed into Docker Compose, with Node.js 20 or newer, PostgreSQL for metadata, Redis for the queue and events, FFmpeg for transcoding, and Nginx for delivery. That makes the repo less a toy “video upload” demo and more a small reference map for how a real streaming backend grows before it needs cloud storage, a content delivery network, or Kubernetes. (github.com)