I'm currently running my entire setup in a single Azure region. This includes an Azure SQL database, a backend API hosted as an Azure Web App, and a frontend app that calls the backend. The backend API has a continuous WebJob that pulls data from third-party sources into the database. Now, I want to implement a multi-region disaster recovery (DR) strategy. The challenge is that if I deploy the backend API and WebJob to a second region, both WebJobs could end up pulling data simultaneously, leading to duplicate entries in the database and inconsistent data. What's the best way to address this using Azure tools? How do developers typically manage background processing like WebJobs across multiple regions to avoid duplicate writes? Should I consider running the WebJob only in one region (active-passive setup)? I'm looking for safe and effective guidance on designing a multi-region DR system for this type of continuous data-pulling application.
2 Answers
I think this is more about your application design than just infrastructure. You could modify your WebJob to create a unique record in the database when it begins processing. If that record already exists, the job should just abort. Once it's finished processing, it can remove that record. This approach will allow multiple WebJobs to run without conflicts, ensuring that only one is writing to the database at a time. There are also other software development strategies to tackle this problem.
Consider using Cosmos DB for your backend; it supports multi-region writes, which can help manage this kind of setup. However, it's crucial to design your application carefully, as multi-region setups can be tricky. Many setups adopt an active-passive model for redundancy, which could simplify things for your WebJob architecture. Focus on solid database design first before diving into the application code.
Sounds like they already have a single-region setup and are just starting to think about disaster recovery. Most of their backend currently relies on WebJobs to pull data continuously from third-party sources.