Resilient Azure Platforms: Durable Functions, Cosmos DB, and DR by Design
Hello Folks! Operating at Azure scale means managing change across multiple interconnected systems. As applications, services, and dependencies evolve, resilience becomes a foundational design principle rather than an afterthought. In this Microsoft Azure Infra Summit 2026 session, Bhavana Konchada, Principal Software Engineer at Microsoft and lead architect of the Resilience Control Platform, takes us behind the scenes of a production-grade resilience platform built on Azure and explains the engineering choices that helped bring it to life. Why IT Pros Should Care Most of us have shipped a system that worked beautifully on day one and then quietly fell apart the first time something downstream blinked. Bhavana’s session is a brutally honest tour of the decisions you make early that determine whether your platform survives reality. Here’s what you walk away with: A pragmatic blueprint for service boundaries that you can actually operate at 2 a.m. Concrete Durable Functions patterns (Monitor, continue-as-new, idempotency) that keep long-running workflows healthy. A Cosmos DB partitioning strategy grounded in real access patterns, not gut feel. A multi-region, fail-and-continue mindset (instead of fail-and-recover) that holds up when a region disappears. Real lessons from production, including the “non-deterministic orchestration” outages nobody warns you about. In short, if you build, run, or modernize platforms on Azure, this session reshapes how you think about reliability. What DR by Design Actually Means, a Technical Overview Bhavana frames the Resilience Control Platform as five chapters: architecture and service boundaries, orchestration with Durable Functions, the Cosmos DB data layer, identity across multiple user realms, and the resilience playbook itself. The platform has four moving parts: A portal where operators define and monitor scenarios. An orchestration engine that executes long-running workflows. Cosmos DB as a shared persistence layer. Downstream infrastructure APIs the engine acts on. The big “DR by Design” idea is that resiliency isn’t bolted on later. It’s a property of every choice from boundaries upward. As Bhavana puts it, you stop designing for “fail and recover” and start designing for “fail and continue.” Users don’t know (or care) which region runs their workflow; they just need it to run reliably, consistently, and without interruption. How It Works, Under the Hood Bhavana’s team made several deliberate design moves worth borrowing. Arm’s-length service boundaries. Version one had the portal and orchestration engine tightly coupled with shared dependency injection and a shared database context. It felt clean until they tried to operate it. Now the two services talk over REST contracts, each with its own dependencies. Yes, that means a bit of duplicated code. What they gained, independent deployments, isolated failures, and clear ownership, more than paid for it. The right runtime for the workload. The portal is a session-driven web app, so it lives on App Service. The orchestration engine bursts on demand and runs workflows for minutes (sometimes hours), so it’s built on Durable Functions. Forcing both into one model would have looked simpler on paper and been worse in practice. Accept Fast, Process Asynchronously. Clicking Execute returns a 202 immediately. The orchestrator does the heavy lifting in the background and updates status in Cosmos DB. The portal just reflects progress. Users never wait on long workflows. Durable Functions patterns that actually scale. Three lessons stood out: The Monitor pattern replaces busy polling with durable timers. The orchestrator wakes up, checks status, and goes back to sleep without holding compute. Orchestrators are state machines, not scripts. Calling DateTime.UtcNow inside an orchestrator produces non-deterministic replay and random production failures. The fix is to use the orchestration context for time and IDs. Continue-as-new keeps replay history bounded. Long-running orchestrations otherwise spend more time replaying history than doing real work. Cosmos DB designed around access, not org charts. Partitioning by tenant feels logical and creates hotspots the moment one tenant gets busy. The team partitions by entity (each plan owns its partition) and uses hierarchical keys combining plan ID and execution ID. They also lean on TTL for data lifecycle so completed records expire automatically, no cleanup jobs required. Identity as an execution boundary. Corporate users authenticate through Microsoft Entra with OpenID Connect. Operations users come in through a federated WS-Federation system. Instead of forking the app, the team built home realm discovery at the front door, normalized everything into a single identity model behind it, and added custom middleware in the Azure Functions isolated worker model to extract, validate, enrich, and fail-fast on every token. Authorization is config-driven so every endpoint gets the same treatment. Multi-region from day one. The full stack (portal, engine, APIs, supporting services) runs in parallel across regions, fronted by Azure Front Door as the global entry point. Health probes drive automatic regional failover with no human in the loop. Cosmos DB single-write with automatic failover. Multi-write looks attractive on a slide and introduces real conflict-resolution complexity. The team chose one primary write region plus a replica with automatic failover. The Cosmos SDK detects region unavailability and routes requests to the promoted region without application code changes. Idempotency from day zero. Once you have retries (and Front Door, the SDK, and your clients all retry), every operation has to be safe to run more than once. Client-provided IDs, Cosmos conflict detection (a 409 means “already succeeded”), and idempotent orchestration events make sure the same outcome lands no matter how many times a signal arrives. Real-World Value, Use Cases, ROI, Scenarios What does this buy you in practice? Scenario validation under stress without compromising production. The platform is built to proactively validate and govern system behavior at scale. Long-running workflows that survive everything. Host restarts, transient downstream errors, regional failovers, none of them lose work in flight. Predictable cost. Durable timers and continue-as-new mean you stop paying for compute that’s only waiting. Operability at scale. Independent services, clean contracts, and centralized identity all mean a smaller cognitive load when something breaks at 2 a.m. Honest tradeoffs. Single-write Cosmos loses theoretical write latency in the second region and gains predictable behavior, no conflict ambiguity, and far easier debugging during failovers. That’s usually the right trade. In short, the platform behaves the same on a quiet Tuesday and during a regional outage. That’s the whole point. Getting Started You don’t need to build the Resilience Control Platform tomorrow. You can start applying these patterns this week. Map your service boundaries honestly. If two services share a DI container or database context, decouple them behind a REST contract. Pick runtimes by workload, not by consistency. Interactive UI on App Service; long-running orchestrations on Durable Functions. Adopt the 202-Accepted pattern for anything that could take more than a couple of seconds. Audit your Durable orchestrators for DateTime.UtcNow, Guid.NewGuid, and direct HTTP calls. Move them into activities, use the orchestration context for time and IDs, and apply continue-as-new on long loops. Revisit your Cosmos partition keys against actual access patterns and enable TTL for transient data. Stand up a second region behind Azure Front Door, enable Cosmos DB automatic failover, and make every write operation idempotent with client-provided IDs. Resources Reliability design principles, Azure Well-Architected Framework Durable Orchestrations overview Azure Durable Functions documentation Azure Functions documentation Hierarchical partition keys in Azure Cosmos DB Azure Cosmos DB documentation Azure Front Door documentation Microsoft Entra ID documentation Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre RomanDesign and Implement Complex Business Scenarios using Low Code Tools
Let’s suppose you oversee any community (such as your school class) using popular chat apps such as Microsoft Teams or Discord. Whenever members join your community, you want them to on-board or – more specifically - verify them. (In case you need an example: In our case, we want competitors for Microsoft Competitions to verify their Discord account when they join the competition Discord server. Once verified, participants will receive broader access to the Discord server.)
