A monolithic application can still have queues; there's no need for them to be coupled with a microservices architecture. They at least afford you a 'fire and forget' decoupling in parts of your code that might be nice. For example, take this action and fire this event. Then in another part of your application you can subscribe to events.
They aren't _queues_ per say but they have a lot of the same DX. Depending on your runtime environment as well, you might benefit from splitting side-effect jobs from your API request/response cycle. That way you can still respond quickly while enqueueing work (locally) all still within a monolith.
Comments
A monolithic application can still have queues; there's no need for them to be coupled with a microservices architecture. They at least afford you a 'fire and forget' decoupling in parts of your code that might be nice. For example, take this action and fire this event. Then in another part of your application you can subscribe to events.
They aren't _queues_ per say but they have a lot of the same DX. Depending on your runtime environment as well, you might benefit from splitting side-effect jobs from your API request/response cycle. That way you can still respond quickly while enqueueing work (locally) all still within a monolith.