The Azure Architecture Center describes the web-queue-worker architecture style as having core components that are a web front end that serves client requests, and a worker that performs resource-intensive tasks, long-running workflows, or batch jobs, with the web front end communicating with the worker through a message queue.
Components
- The web front end serves client requests, handles authentication and authorization.
- The front end queues commands for intensive or long-running workloads in the message queue for the worker to consume. This allows the web application to remain independent of the worker's workload and to immediately respond to HTTP requests.
- The worker receives work from the message queue. Results can be stored in the data store.
- Both worker and front end might access the data store directly to access business data and process state. An optional cache might be used for performance optimizations.
- A Content Delivery Network can help to serve static content even faster and reduce load on the web front end.
Challenges
- Not every operation on the database has to go through the worker. The web front end can perform simple read/write or time-sensitive operations directly. Workers are designed for resource-intensive tasks or long-running workflows.
- This style is suitable for simple business domains. Without careful design, the front end and the worker can become complex, monolithic components that are difficult to maintain. Consider event-driven and microservices architectural styles for more complex business domains.
Technology choices
The web-queue-worker architecture style can make use of Azure's managed services like Azure App Services, Azure Static Web Apps, Azure Functions, and Cosmos DB. Azure Service Bus is powerful messaging technology choice. When relying on a Infrastructure-as-a-Service model, web-queue-worker architectures might provide fewer benefits.