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
OKTO TECHNOLOGIES 