Resilient Azure Platforms: Durable Functions, Cosmos DB, and DR by Design

Hi there, everyone!

When you’re working at the scale of Azure, managing change across a web of interconnected systems is crucial. As applications, services, and their dependencies evolve, building resilience into your designs isn’t just an option—it’s essential. In this session from the Microsoft Azure Infra Summit 2026, Bhavana Konchada, a Principal Software Engineer at Microsoft and lead architect of the Resilience Control Platform, shares insights into creating a robust resilience platform on Azure and discusses the engineering decisions that shaped its development.

We’ve all experienced that moment when a system worked flawlessly at launch but fell apart when faced with unexpected issues downstream. Bhavana’s session offers a candid look at the decisions made early on that can spell the difference between a resilient platform and one that crumbles under pressure. Here’s what you’ll take away:

• A practical guide for defining service boundaries that are manageable, even at 2 a.m.
• Proven Durable Functions patterns (Monitor, continue-as-new, idempotency) that ensure long-running workflows remain healthy.
• A Cosmos DB partitioning strategy based on real access patterns instead of guesswork.
• A mindset of multi-region fail-and-continue rather than fail-and-recover, so the system holds up even if a region goes offline.
• Valuable lessons from production experiences, including the often-overlooked “non-deterministic orchestration” outages.

In essence, if you’re involved in building, running, or improving platforms on Azure, this session will change how you approach reliability.

Bhavana presents the Resilience Control Platform in five chapters: architecture and service boundaries, orchestration with Durable Functions, the Cosmos DB data layer, identity management across various user realms, and the resilience playbook itself.

The platform comprises four key components:

• A portal where operators can define and monitor scenarios.
• An orchestration engine that executes long-running workflows.
• Cosmos DB serving as a shared persistence layer.
• APIs for downstream infrastructure that the engine interacts with.

The core idea of “DR by Design” is that resilience must be integrated from the start, not added to the system later. As Bhavana puts it, shift from designing for “fail and recover” to “fail and continue.” Users don’t care about which region runs their workflow—they just need it to operate reliably and consistently without interruptions.

Bhavana’s team implemented several intentional design choices that are worth emulating:

Clear service boundaries: In the initial version, the portal and orchestration engine were tightly integrated, sharing dependencies and a database context. This seemed neat until they began to operate it. Now, the two services communicate via REST contracts, allowing for individual dependencies. While there is some code duplication, the benefits of independent deployments, isolated failures, and clear ownership far outweigh the costs.

Choosing the right runtime for your workload: The portal functions as a session-driven web app hosted on App Service, while the orchestration engine is designed to handle workflows that can run for minutes or even hours, built on Durable Functions. Merging these into one model could have looked straightforward on paper but would have caused practical complications.

Fast acceptance, asynchronous processing: When a user clicks ‘Execute’, a 202 response is returned immediately. The actual processing occurs in the background, with status updates reflected in Cosmos DB. This way, users never have to wait on lengthy workflows.

Scalable Durable Functions patterns: Here are three standout lessons:

• The Monitor pattern replaces constant polling with durable timers. The orchestrator wakes up, checks on progress, then returns to sleep without wasting compute resources.
• Orchestrators function as state machines, not scripts. Using DateTime.UtcNow inside an orchestrator can lead to non-deterministic replays and random production failures. The solution is to utilise the orchestration context for time and IDs.
• Utilising continue-as-new helps keep replay history manageable. Otherwise, long-running orchestrations might spend more time replaying old data rather than completing tasks.

Cosmos DB designed for actual access patterns: Instead of partitioning by tenant—which can result in hotspots if one tenant is busy—the team partitions by entity, with each plan owning its partition. They also employ hierarchical keys that combine plan ID and execution ID and use TTL for data management to allow completed records to expire automatically, eliminating the need for clean-up jobs.

Identity as an execution boundary: Corporate users authenticate through Microsoft Entra using OpenID Connect, while operations users access via a federated WS-Federation system. Rather than splitting the app, the team designed home realm discovery at the entry point, normalising everything into a single identity model, and implemented custom middleware within the Azure Functions isolated worker model to extract and validate tokens efficiently. Authorisations are config-driven, ensuring all endpoints receive uniform treatment.

Multi-region capabilities from the outset: The entire stack (portal, engine, APIs, and support services) runs parallel across regions, managed by Azure Front Door as the global access point. Health checks facilitate automatic regional failover without requiring manual intervention.

Cosmos DB with single-write and automatic failover: While multi-write may seem appealing on paper, it introduces conflict-resolution complexities. The team opted for one primary write region supplemented by a replica with automatic failover. The Cosmos SDK identifies region unavailability and reroutes requests to the promoted region, all without needing application code alterations.

Idempotency from day zero: With retries being commonplace, every operation must be capable of safely executing multiple times. Implementing client-provided IDs, using Cosmos conflict detection (where a 409 indicates “already succeeded”), and making orchestration events idempotent ensures consistency regardless of how often a signal is sent.

So, what practical benefits does this approach deliver?

• Scenario validation under stress: The platform is designed to proactively validate and govern system behaviour on a large scale without disrupting production.
• Long-running workflows that can withstand anything: Host restarts, transient downstream errors, and regional failovers won’t result in lost progress.
• Predictable costs: Durable timers and continue-as-new features help eliminate charges for resources that aren’t actively utilised.
• Easier operations at scale: With independent services, clear contracts, and centralised identity management, the cognitive load is minimised, especially during issues late at night.
• Realistic trade-offs: A single-write Cosmos setup sacrifices theoretical write latency in the secondary region but gains predictable behaviour, clarity in conflicts, and simplified debugging during failovers. Often, this is the more sensible choice.

Ultimately, the platform behaves consistently on a calm Tuesday as well as during a regional outage—that’s the goal.

You don’t have to roll out the Resilience Control Platform immediately. You can start implementing these strategies as soon as this week:

1. Map out your service boundaries honestly. If two services use a shared DI container or database context, uncouple them behind a REST contract.
2. Select runtimes based on workload requirements rather than consistency needs. For example, use App Service for interactive UIs and Durable Functions for long-running orchestrations.
3. Adopt the 202-Accepted pattern for any processes that could take longer than a few seconds.
4. Review your Durable orchestrators for DateTime.UtcNow, Guid.NewGuid, and direct HTTP calls. Move those to activities, utilise orchestration context for timing and IDs, and apply continue-as-new for lengthy loops.
5. Reassess your Cosmos partition keys against real access patterns and enable TTL for temporary data.
6. Set up a second region behind Azure Front Door, activate Cosmos DB automatic failover, and make every write operation idempotent with client-provided IDs.

Don’t miss the complete Microsoft Azure Infra Summit 2026 session playlist here.

Take care!

Pierre Roman