--- title: Resilience Patterns Can Make Your System Less Resilient description: Standard resilience advice like retries, circuit breakers, and fallbacks can make distributed systems less resilient rather than more, because these patterns... canonical: https://daily.dev/posts/resilience-patterns-can-make-your-system-less-resilient-vpit31zhs twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Resilience Patterns Can Make Your System Less Resilient | daily.dev og:description: Standard resilience advice like retries, circuit breakers, and fallbacks can make distributed systems less resilient rather than more, because these patterns... og:url: https://daily.dev/posts/resilience-patterns-can-make-your-system-less-resilient-vpit31zhs og:image: https://api.daily.dev/og/posts/VPIt31zhS.png og:image:alt: Resilience Patterns Can Make Your System Less Resilient og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Resilience Patterns Can Make Your System Less Resilient **[CodeOpinion](https://daily.dev/sources/codeopinion)** · [@codeopinion](https://daily.dev/codeopinion) · 12 min read · 0 upvotes · 0 comments ## Summary Standard resilience advice like retries, circuit breakers, and fallbacks can make distributed systems less resilient rather than more, because these patterns consume resources in ways that aren't always accounted for. Using a worker consuming queue messages and calling a third-party shipping API as an example, the piece explains how retries can occupy workers for extended periods, backlog message brokers, and turn short failures into multi-minute delays. The core argument is that not all failures are the same: something being down fails fast and is easy to detect, while something being slow silently occupies resources and delays detection. The recommendation is to classify failure modes (down, slow, degraded, intermittent, overloaded), use metrics like failure rate and timeout rate shared across distributed worker instances to make faster systemwide decisions, and design resilience choices around the specific resource being consumed and the blast radius of the failure rather than reflexively applying standard patterns. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### why do retries make my distributed system worse instead of more resilient Retries are not free because they consume a resource, typically a worker's processing time, while it waits on a failing call. If a third-party API is slow rather than down, a retry policy with backoff (e.g., 500ms, 2s, 10s, 30s, 100s) can turn a 30-second failure into minutes per message, backlogging the queue since workers stay occupied instead of processing other messages. _Teams tuning retry and circuit breaker policies for message queue workers can find deeper architecture discussion on daily.dev._ ### what is the difference between a service being down versus being slow for resilience design A service that is down fails fast, typically returning a 503 or connection refused immediately, making it easy to detect and allowing a circuit breaker to open quickly. A slow or degraded service is harder to classify and more damaging because workers sit occupied waiting on it, delaying detection of the real failure and blocking other work from being processed. _Developers debugging flaky third-party integrations can track these failure-classification patterns on daily.dev._ ## Similar posts on daily.dev - [3 Resilience Patterns That Keep a Backend Service Up When Its Dependencies Aren't](https://daily.dev/posts/3-resilience-patterns-that-keep-a-backend-service-up-when-its-dependencies-aren-t-by1axueza) · The T-Shaped Dev · 0 upvotes · 0 comments - [Sometimes, the most resilient thing a system can do isn’t retry](https://daily.dev/posts/sometimes-the-most-resilient-thing-a-system-can-do-isn-t-retry-5dzqopjri) · ITNEXT · 1 upvotes · 0 comments - [5 Resilience Patterns for AI Agents](https://daily.dev/posts/5-resilience-patterns-for-ai-agents-oiijblpah) · The T-Shaped Dev · 1 upvotes · 0 comments - [The ‘Super Bowl’ standard: Architecting distributed systems for massive concurrency](https://daily.dev/posts/the-super-bowl-standard-architecting-distributed-systems-for-massive-concurrency-mvxs8yfr2) · InfoWorld · 0 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#distributed-systems](https://daily.dev/tags/distributed-systems) [View this post on daily.dev](https://daily.dev/posts/resilience-patterns-can-make-your-system-less-resilient-vpit31zhs) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Resilience Patterns Can Make Your System Less Resilient","url":"https://daily.dev/posts/resilience-patterns-can-make-your-system-less-resilient-vpit31zhs","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/resilience-patterns-can-make-your-system-less-resilient-vpit31zhs"},"datePublished":"2026-10-04T13:07:04.153Z","dateModified":"2026-10-05T10:00:18.696Z","description":"Standard resilience advice like retries, circuit breakers, and fallbacks can make distributed systems less resilient rather than more, because these patterns...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4c98773a453dacee2ee1040c4990ec5b?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4c98773a453dacee2ee1040c4990ec5b?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"CodeOpinion","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Person","name":"Derek Comartin","url":"https://daily.dev/codeopinion","image":"https://lh3.googleusercontent.com/a-/AOh14GgoQapb7NmLN1TZ6L-UCxkRpDZ4H7LKwud1DUZCTSI=s100","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":950}},"commentCount":0,"discussionUrl":"https://daily.dev/posts/resilience-patterns-can-make-your-system-less-resilient-vpit31zhs","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,distributed-systems","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"CodeOpinion","item":"https://daily.dev/sources/codeopinion"},{"@type":"ListItem","position":3,"name":"Resilience Patterns Can Make Your System Less Resilient"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/resilience-patterns-can-make-your-system-less-resilient-vpit31zhs#faq","mainEntity":[{"@type":"Question","name":"why do retries make my distributed system worse instead of more resilient","acceptedAnswer":{"@type":"Answer","text":"Retries are not free because they consume a resource, typically a worker's processing time, while it waits on a failing call. If a third-party API is slow rather than down, a retry policy with backoff (e.g., 500ms, 2s, 10s, 30s, 100s) can turn a 30-second failure into minutes per message, backlogging the queue since workers stay occupied instead of processing other messages. Teams tuning retry and circuit breaker policies for message queue workers can find deeper architecture discussion on daily.dev."}},{"@type":"Question","name":"what is the difference between a service being down versus being slow for resilience design","acceptedAnswer":{"@type":"Answer","text":"A service that is down fails fast, typically returning a 503 or connection refused immediately, making it easy to detect and allowing a circuit breaker to open quickly. A slow or degraded service is harder to classify and more damaging because workers sit occupied waiting on it, delaying detection of the real failure and blocking other work from being processed. Developers debugging flaky third-party integrations can track these failure-classification patterns on daily.dev."}}]} ```