Problem
Video automation workflows become fragile when orchestration, processing, storage, and delivery are mixed together without clear state or service boundaries.
Constraints
- Private project; do not claim public usage, customer scale, or open-source status.
- Media workflows require clear state transitions, repeatable processing steps, and careful storage/delivery boundaries.
- Architecture must stay understandable despite multiple services and asynchronous jobs.
What I built
Design a queue-driven platform where orchestration, worker processing, storage handling, and delivery are separated into understandable operational responsibilities.
Architecture
Node.js/TypeScript services with queue-driven jobs, state-based orchestration, Supabase-backed workflow state where appropriate, AWS/object-storage integration, FFmpeg-style media processing, and delivery workflow boundaries.
Public UI
Typed API boundary
Database-backed content
Decisions and trade-offs
- Use a queue-driven model to separate orchestration from processing.
- Treat job state as a central concept so workflows can be reasoned about and recovered.
- Separate storage, processing, and delivery responsibilities.
- Prefer clear service boundaries over a monolithic script that is difficult to operate.
Outcome
A private implementation proof for automation-heavy backend/platform work: queues, orchestration, workers, storage, FFmpeg-style processing, and delivery workflows.
Repository context
Private build. Architecture and tradeoffs can be discussed in interviews; do not present as public/open-source unless intentionally changed.