> Markdown version of [/videos/1551-building-resilient-net-applications-for-the-modern-age?t=224](https://www.wearedevelopers.com/videos/1551-building-resilient-net-applications-for-the-modern-age?t=224). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Building resilient .NET applications for the modern age

System outages cost millions. Stop relying on naive error handling. Build fault-tolerant .NET applications using Polly, Aspire, and chaos engineering to prevent cascading failures.

- **Speakers:** [Sander ten Brinke](https://www.wearedevelopers.com/@sander-ten-brinke)
- **Event:** World Congress 2025
- **Published:** August 20, 2025
- **Duration:** 28:31
- **URL:** https://www.wearedevelopers.com/videos/1551-building-resilient-net-applications-for-the-modern-age

## Summary

System resilience remains an afterthought for many organizations until an outage incurs massive financial costs, with unhandled network latency and microservice complexities acting as primary culprits. Recognizing that "uptime is not just a metric, it's an actual mindset" requires developers to build systems that are gracefully degradable and recoverable by design. Transitioning from naive error handling—like hardcoded retry loops—to robust fault-tolerance strategies prevents localized failures from cascading across distributed environments.

The open-source Polly library provides a declarative, pipeline-based approach to managing transient faults natively within .NET. Effective implementation relies on nuanced strategies: retry mechanisms must employ exponential backoff and jitter to avoid overwhelming recovering services in a "thundering herd" scenario, while circuit breakers intelligently sever traffic to failing dependencies to preserve system resources. Furthermore, concurrency rate limiters ensure predictable throughput even under aggressive traffic spikes by dictating exactly how many requests may proceed simultaneously.

Verifying these safeguards demands proactive chaos engineering, deliberately injecting latency, exceptions, or unpredictable behavior to prove system robustness before a real crisis hits. To streamline this implementation and avoid counterproductive misconfigurations, the microsoft.extensions.http.resilience package—part of the .NET Aspire toolkit—injects intelligent defaults directly into HTTP clients. By automatically handling rate limits, optimal timeouts, and contextual retries, engineering teams can seamlessly decouple domain logic from infrastructure constraints while guaranteeing distributed state reliability.

**Keywords:** .net core resilience, microservices architecture, transient fault handling, polly library, exponential backoff jitter, circuit breaker pattern, thundering herd problem, concurrency rate limiting, chaos engineering simulation, microsoft.extensions.http.resilience, dotnet aspire toolkit, graceful degradation, modular monoliths, distributed system latency, automated retry pipeline

## Chapters

1. **The growing cost of system outages and microservice failures** (00:05) — As microservices introduce network latency and complexity, system resilience becomes an essential upfront requirement to maintain application availability.
1. **Defining software resilience and layers of system architecture** (03:44) — Comprehensive resilience requires strategic planning across infrastructure scaling, disaster recovery plans, software architecture choices, and system observability.
1. **Replacing manual retry logic with the Polly library** (08:25) — Hardcoded retry loops cause traffic spikes and scaling issues, which can be mitigated by using dedicated transient fault handling libraries.
1. **Configuring resilience pipelines and exponential backoff retry strategies** (11:56) — Implementing a retry pattern with exponential backoff and jitter spreads out network requests to prevent thundering herd problems.
1. **Halting traffic to failing dependencies using circuit breakers** (14:51) — The circuit breaker pattern evaluates failure thresholds over time and halts outgoing requests to allow failing downstream services time to recover.
1. **Preventing service overloads with concurrency rate limiting** (17:34) — Applying concurrency limiters manages sudden traffic surges by restricting the maximum number of simultaneous requests allowed through a pipeline.
1. **Integrating resilience pipelines directly into HTTP client registrations** (19:05) — Attaching resilience handlers directly to HTTP client configurations simplifies integration and cleanly separates cross-cutting technical concerns from core business logic.
1. **Testing application robustness by injecting faults with chaos engineering** (20:21) — Testing pipeline robustness in production can be achieved by injecting deliberate latency, faults, and custom failure behaviors into the system.
1. **Applying reliable defaults using Microsoft Extensions HTTP Resilience** (22:34) — Official HTTP resilience extensions streamline setup by providing curated pipeline defaults for rate limiting, sliding timeouts, and retry policies.

## Related Moments

- [Enhancing distributed application resilience using the Polly project](https://www.wearedevelopers.com/videos/967-this-is-not-your-father-s-net) (from "This Is Not Your Father's .NET")
- [Identifying examples of system resilience and fragility in technology](https://www.wearedevelopers.com/videos/100037-beyond-resilience-architecting-antifragile-systems) (from "Beyond Resilience: Architecting Antifragile Systems")
- [Balancing strict application boundaries with resilient execution architectures](https://www.wearedevelopers.com/videos/100285-stop-parsing-strings-treating-llms-like-type-safe-microservices) (from "Stop Parsing Strings: Treating LLMs Like Type-Safe Microservices")
- [Understanding system resilience and the costs of failure](https://www.wearedevelopers.com/videos/874-system-resilience-surviving-the-software-storm) (from "System Resilience: Surviving the Software Storm")
- [Navigating complexity and anti-patterns in modern software architecture](https://www.wearedevelopers.com/videos/874-system-resilience-surviving-the-software-storm) (from "System Resilience: Surviving the Software Storm")
- [Building robust system resilience across all stack layers](https://www.wearedevelopers.com/videos/874-system-resilience-surviving-the-software-storm) (from "System Resilience: Surviving the Software Storm")

## Related Articles

- [Walking Into The Era of Supply Chain Risks](https://www.wearedevelopers.com/magazine/106-walking-into-the-era-of-supply-chain-risks)
- [Dev Digest 138 - Are you secure about this?](https://www.wearedevelopers.com/magazine/486-dev-digest-138-are-you-secure-about-this)
- [Dev Digest 139 - Soft and hard queries](https://www.wearedevelopers.com/magazine/487-dev-digest-139-soft-and-hard-queries)
- [Why Presentations Should Always Work Offline—Even at Online Conferences](https://www.wearedevelopers.com/magazine/602-why-presentations-should-always-work-offline-even-at-online-conferences)

## Related Jobs

- [Senior Engineer, Infrastructure Platform](https://www.wearedevelopers.com/jobs/ext/328836-senior-engineer-infrastructure-platform) at **Intercom, Inc.**
- [Senior Software Engineer, Client Apps Platform](https://www.wearedevelopers.com/jobs/ext/1773893-senior-software-engineer-client-apps-platform) at **GitHub**
- [Software Engineer, Platform Engineering (L2)](https://www.wearedevelopers.com/jobs/ext/1956829-software-engineer-platform-engineering-l2) at **Twilio**
- [Senior Software Engineer, Enterprise Products](https://www.wearedevelopers.com/jobs/ext/1841248-senior-software-engineer-enterprise-products) at **GitHub**
- [Senior Software Engineer](https://www.wearedevelopers.com/jobs/ext/591545-senior-software-engineer) at **Twilio**
- [Principal Software Engineer](https://www.wearedevelopers.com/jobs/ext/149130-principal-software-engineer) at **Twilio**