This was kind of a wild read. It starts with

> When I started building the Call Kent feature, I could have designed a proper job queue with a dedicated worker pool. But that would have been solving a scalability problem I did not yet have. "Start simple and iterate when reality tells you to" is still how I think about this. Reality finally told me.

And then we find ourselves at

> The signature uses HMAC-SHA256 with a shared secret, verified with a timing-safe comparison to avoid leaking information through response time.

Yikes, the complexity!

It took me thirty seconds to find the fly.io guidance to use BullMQ with Node+Redis.

https://fly.io/docs/blueprints/work-queues/

The recommendation is three lines of code. Instead, we have a queue, a queue worker, and an ffmpeg container running on two different vendors with two new internal API calls between services.

But also, this could all have been done in the browser. I did this ten years ago! https://pinecoder.pinecast.com

Start simple is fine, but this solution really seems like it overshot.