[robertandrewp]

One approach that sidesteps the whole problem: design for fully synchronous, stateless requests from the start so there's nothing to queue.

I did this for a financial calculator API — every request is pure computation, inputs in, result out, nothing persisted. No Redis, no workers, no task table, no locking. The response is ready before a user would notice a queue anyway (sub-50ms).

Obviously only works when tasks complete in milliseconds. But figassis's pattern of "starts simple, then incrementally grows into a small job system anyway" often happens because the initial scope could have been fully synchronous — the async complexity creeps in before it's actually needed.

Worth asking first: does this task genuinely have to be async, or is it just easier to model it that way?

[sergF]

Yeah, that makes sense too. I also try to keep things synchronous as long as possible.

In practice async usually shows up once there are external APIs, retries, scheduling, or anything that shouldn't block the request, and that's where I end up building some kind of job system again.

I'm trying to figure out if that point happens often enough to justify moving this outside the app entirely.