Azure Application Architecture : Web-Queue-Worker

The center of a web-queue-worker architecture is based on the web front-end. The web front-end communicates with the worker using a messaging queue system. The worker is optional. If the application need to perform resource-intensive tasks, long-running workflows, or batch jobs then a worker is needed.

Any long-running work is done asynchronously by the worker. The worker can be triggered by messages on the queue, or run on a schedule for batch processing.

The front-end is implemented as an Azure App Services as well as the WebJob.

Others components that can be added to the architecture :

  • Databases
  • A cache to store values from the database for quick reads
  • CDN to serve static content
  • Remote services, such as email or SMS service. Often these are provided by third parties
  • Identity provider for authentication

All those components are managed services (PaaS) within the Azure portal.


When to use the web-queue-worker architecture

  • When you build a relatively simple domain application
  • When the application requires some long-running workflows or batch operations
  • When you want to use managed services instead of an IaaS architecture



  • Easy to understand and to put in place
  • Easy to deploy and manage
  • Clean separation of concerns
  • The front end is decoupled from the worker using asynchronous messaging
  • The front end and the worker can be scaled independently
  • No IaaS architecture to manage like in the n-tier architecture
  • Managed services are easier to configure and administer


  • Without careful design, the front end and the worker can become large, monolithic components that are difficult to maintain and update
  • There may be hidden dependencies, if the front end and worker share data schemas or code modules


Best practices

  • Expose a well-designed API to the client
  • Configure auto-scaling to handle changes in load
  • Use cache to store sessions state
  • Use a CDN to host static content such as images, CSS or HTML
  • Select different storage technologies that best fit the needs of the application
  • Partition data to improve scalability, reduce contention, and optimize performance
  • Put the web app and the webjob in a different App Services plan to be hosted on different VM instances and scaled independently

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s