Resilience patterns for .NET 10 applications using Polly v8. Covers retry, circuit breaker, timeout, fallback, rate limiter, hedging, and composing resilience pipelines. Load this skill when implementing retry logic, circuit breakers, handling transient failures, or when the user mentions "Polly", "

Resilience Core Principles 1. Polly v8 resilience pipelines, not v7 policies — Polly v8 replaced Policy with ResiliencePipeline . Never use PolicyBuilder , Policy.Handle< () , or ISyncPolicy . The new API is composable, type safe, and integrates natively with IHttpClientFactory . 2. Configure via AddResilienceHandler , not manual wrapping — For HTTP calls, use Microsoft.Extensions.Http.Resilience which adds pipelines directly to HttpClient via DI. No manual ExecuteAsync wrapping. 3. Compose strategies, don't nest them — A single ResiliencePipeline can chain retry + circuit breaker + timeout. Strategies execute outer to inner (first added = outermost). No need for nested try/catch or manual orchestration. 4. Always set timeouts — Every external call needs a timeout. Use Polly's AddTimeout() as the innermost strategy so it applies per attempt, and optionally an outer timeout for total elapsed time. 5. Instrument everything — Polly v8 emits Metering events and supports TelemetryOptions for OpenTelemetry. Use them to monitor retry rates, circuit breaker state, and timeout frequency. Patterns HTTP Client Resilience (Recommended Default) Why : AddStandardResilienceHandler() from Microsoft.Extensions.Http.Resilience applies production ready defaults. Override only when you need different thresholds. Custom HTTP Resilience Configuration Why : Named resilience handlers let you tune per service. The order matters: total timeout retry circuit breaker attempt timeout. Non HTTP Resilience Pipeline Why : AddResiliencePipeline registers a named pipeline in DI. Inject with [FromKeyedServices] for clean, testable code. Typed Resilience Pipeline Why : Typed pipelines let you add fallback strategies that return a default value when all retries are exhausted — critical for graceful degradation. Hedging (Parallel Requests) Why : Hedging sends a parallel request if the first hasn't responded within the delay. Use for latency sensitive reads where you can tolerate duplicate work. Telemetry Integration Rate Limiting (.NET Built in) .NET provides built in rate limiting middleware via AddRateLimiter() — no external packages needed. Algorithms: AddFixedWindowLimiter , AddSlidingWindowLimiter , AddTokenBucketLimiter , AddConcurrencyLimiter . Anti patterns BAD: Using Polly v7 API GOOD: Polly v8 Resilience Pipeline BAD: Wrapping Every Call Manually GOOD: Pipeline Handles Everything via HttpClient DI BAD: Retry on Non Idempotent Operations GOOD: Retry Only Idempotent Operations or Use Idempotency Keys BAD: Circuit Breaker Without Monitoring GOOD: Circuit Breaker with Telemetry Decision Guide Scenario Strategy Configuration HTTP calls to external APIs AddStandardResilienceHandler() Use defaults, override only specific thresholds HTTP with custom thresholds AddResilienceHandler("name", ...) Named handler with per service tuning Database / EF Core calls AddResiliencePipeline("db", ...) Retry on deadlock/timeout, no circuit breaker Message queue publishing AddResiliencePipeline("mq", ...) Retry with exponential backoff, timeout Latency sensitive reads AddHedging(...) Parallel request after delay threshold Graceful degradation AddFallback(...) Return cached/default value on total failure Per attempt time limit AddTimeout(...) innermost 2 10s depending on operation Total operation time limit AddTimeout(...) outermost Sum of all retries + buffer Non idempotent writes Retry with idempotency key Or no retry — fail fast Read heavy microservice Standard handler + hedging Low latency with redundancy API rate limiting AddRateLimiter() + RequireRateLimiting() Fixed, sliding, or token bucket per endpoint