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

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/ 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 https://pinecoder.pinecast.com Start simple is fine, but this solution really seems like it overshot.