> If it’s polling for status from the backend doesn’t that defeat the purpose of having a worker to begin with? It depends. If you needed a coordination layer

> If it’s polling for status from the backend doesn’t that defeat the purpose of having a worker to begin with? It depends. If you needed a coordination layer or you needed to isolate certain types of traffic then it makes more sense. I assume your alternative here is "why not just have a new client tier doing work" which is a reasonable architecture too > One aspect of this set up I’ve never been able to understand is how the application then gets the result from the worker? Often they don't in these architectures. I found it a little strange that a job queue was being used to serve (what seems like) synchronous traffic. Usually I see job queues in the wild used for async/send-and-forget workloads Personally I would rather chain multiple synchronous service calls if I needed a synchronous workflow. It's just simpler to me to stick web workers behind a load balancer and scale that. This is less elegant when things take a very long time though or are prone to retries. Either the client or server needs to be responsible for queuing/message persistence/retries - with services the client does it, with job queues the server does it