When retries become the outage

The first failed request is often the least interesting part of an outage. A dependency takes longer than expected, one caller gives up waiting, and the application tries again. That looks like a sensible recovery action. The difficulty appears when thousands of other callers reach the same conclusion, several layers make their own attempts, and the original work is still running. The system is now spending a growing share of its capacity on recovering from the load created by its recovery mechanisms. Nothing in an individual retry loop needs to look obviously unreasonable for the combined behaviour to become destructive.

Consider an explicitly hypothetical order-status service. It normally has enough capacity for its incoming work, but a downstream dependency slows for two minutes. Requests remain in flight longer, the caller's timeout starts expiring, and a client library begins another attempt. An outer service also has a retry policy. A user interface offers a retry button because its own deadline has passed. The business demand has barely changed, yet the dependency sees more attempted work precisely when it can complete less. This article follows that chain, then examines the places where a design can interrupt it. The scenario and every numerical example are illustrative, not an account of an MGCA customer incident or a measured benchmark.

A retry is a new request for resources, even when it represents an old intention. That distinction is the starting point for understanding the failure. The business may still want one status update, one submitted application or one completed report. The infrastructure may be processing several attempts to produce it. If dashboards count requests without connecting them to the underlying operation, the extra activity can look like a surge in customer demand. If success is measured per attempt rather than per useful outcome, the service can also appear healthier than the experience of the person waiting for it.

1. A small delay acquires a second life

A timeout answers a local question: how long will this caller wait? It does not, by itself, answer whether the remote operation stopped, failed before execution or completed without delivering its acknowledgement. Those are different outcomes. For a read, repeating the request may mainly consume resources. For a write, an uncertain outcome can also create a correctness problem. The receiving system might already have committed the change. The caller's desire to receive a definite answer does not make another execution safe. Capacity protection and business correctness therefore need to be considered together, rather than assigning retries to a transport layer and assuming the rest of the application is unaffected.

The first response to a slowdown is often to increase the timeout. That can reduce false failures where normal variation was being mistaken for an outage. It can also keep more requests occupying resources for longer. Lowering the timeout creates the opposite trade-off: callers release their waiting state sooner, but may initiate replacement attempts while the previous work remains active. Neither direction is inherently correct. The useful question is which resources remain occupied, which work actually stops, and how the chosen deadline relates to the value of completing the task. Changing a number without answering those questions can move the pressure rather than remove it.

There is also more than one clock. Establishing a connection, resolving a name, obtaining an identity token, waiting for a pooled connection and receiving the response can each consume part of the caller's available time. A request timeout that excludes an earlier wait can give a misleading impression of the total operation. Conversely, independently generous allowances at every stage can produce an overall delay far beyond the user-facing promise. A design needs a coherent account of elapsed time, including time spent before the remote call begins and between attempts. The important boundary is the whole task, not whichever timer happens to be easiest to configure.

In the hypothetical service, imagine that the visible page stops waiting after five seconds while an inner client is permitted to continue for twenty. Those values are not recommended settings. They expose an ownership problem. For part of that period the service may be working on a request whose original reader has already left. If the page submits a fresh operation, the old work and new work compete. If cancellation is propagated, the receiving component still needs to define what it can cancel safely. Stopping a network wait and undoing a committed transaction are not the same capability. A deadline can end the usefulness of a result without reversing its effects.

The first interruption point is consequently a deadline that has an owner. A component should know how much of the operation's remaining time it may spend, whether another attempt can plausibly finish within it, and what happens when that time is exhausted. The answer may be a clear failure, a retained asynchronous operation with a status reference, or a result marked as incomplete. It should not be an invisible transfer of the same work into another unbounded retry loop. A recovery policy is useful when it improves the chance of a valid outcome within the task's actual constraints.

Amazon's engineering guidance discusses timeouts, backoff, jitter and the risk that a timed-out call has already produced side effects. Microsoft describes the related retry-storm antipattern: frequent attempts can prevent a struggling service from recovering. These sources support the broad mechanism, rather than validating the particular numbers in this article. The design reasoning that follows applies that mechanism to a deliberately simplified service so that the consequences remain inspectable. [1] [2]

2. The multiplication happens between teams

Three attempts sound modest. Three layers each allowing three total attempts can be quite different. Under the specific worst-case assumption that every outer attempt causes all inner attempts, and none succeeds early, the deepest dependency can receive twenty-seven attempts for one original operation. This is multiplication across the call hierarchy, not a claim that every failure automatically produces that count. Cancellation, deadlines, early success, circuit state and the actual ownership of the retry can reduce it. The point of the calculation is to expose an interaction that is easy to miss when each component is reviewed independently.

Terminology matters here. A setting described as three retries may mean an original attempt plus three more, whereas three attempts includes the original. Confusing those definitions changes the calculation before any implementation detail enters it. An architecture discussion should write down the total attempts allowed at each boundary and identify which component starts them. It should also include behaviour supplied by client libraries, gateways and infrastructure. A diagram that shows only application code can omit the retry mechanism that dominates the traffic. The component that hides a fault from its caller still contributes to the system's workload.

The organisational cause is understandable. Each team wants its own service to tolerate a brief interruption. A shared library adopts a standard policy. A gateway adds another layer of protection. A worker treats an exception as a reason to abandon and receive the message again. None of these choices needs to be careless. The failure emerges because the policies share a dependency without sharing a budget. Local resilience has become collective optimism: every participant assumes that another attempt is affordable, while no participant is responsible for the total number of attempts the business operation can generate.

The radial diagram at the opening makes this visible. Its rings represent one original operation, then three, nine and twenty-seven possible downstream attempts in a deliberately constrained model. The rings are not measured traffic and their areas are not performance estimates. They are a way to inspect the branching assumption without drawing another rectangular application landscape. Follow a single intention outward and ask where new work is created. If several layers can independently expand it, reviewing only the final client's maximum retries will not establish the maximum load the whole route can impose.

One practical response is to make retry ownership explicit at the boundary where the application has enough context to judge the operation. That does not mean every system should centralise all resilience logic in one place. A transport may reasonably recover a broken connection while an application manages a longer task. The requirement is that their combined behaviour is understood and bounded. A lower layer should not silently restart a full business action after the upper layer believes it has exhausted the task's allowance. The boundary between reconnecting, resending and re-executing needs to be visible in both design and observation.

A retry budget adds a second limit beyond the per-request maximum. The application can constrain the aggregate amount of extra work it introduces during failure. The accounting unit must be chosen deliberately: requests, concurrent attempts, elapsed time, a weighted cost or a combination. A cheap cached read and an expensive report are not necessarily interchangeable tokens. The mechanism should also define what happens when the budget is empty. Simply moving rejected retries to a private queue preserves the pressure while hiding it from the original limiter. A useful budget changes the behaviour that reaches the constrained resource.

There is no universal percentage that makes such a budget correct. The available recovery capacity, dependency contract, task value and failure behaviour differ. A service might reserve a narrow allowance for short transient errors while refusing to multiply expensive work during persistent failure. Another might defer eligible tasks to a separately controlled background process. What matters is that the policy remains meaningful when the system is stressed, when successes are scarce and when several callers fail together. A budget whose replenishment depends on success needs an explicit interpretation of that low-success period, rather than an accidental lockout or an unlimited emergency override.

A failed attempt is not a new business instruction

For a write-capable service, the operation's identity needs to survive the attempt. If a client generates a fresh business identifier each time it resends the same intention, a receiver may reasonably treat the requests as different operations. If it reuses an identifier without checking the associated content, the same key might become attached to materially different changes. An idempotency design therefore needs more than a field named request ID. It needs a scope, a relationship to the intended action, a retention period and a defined response when a repeated identifier arrives with incompatible content.

The result record matters just as much. If the receiver can identify a completed operation but cannot recover its outcome, the caller may remain uncertain even though duplicate execution is prevented. The service should decide whether it can return the previous result, provide a status reference or require investigation. The correct arrangement depends on the operation and its information-handling requirements. The general distinction is stable: recognising an old instruction, preventing another effect and explaining the existing effect are related capabilities, but they are not automatically delivered by the same mechanism.

3. Waiting rooms do not create capacity

A queue can make a workload easier to control. It separates acceptance from execution and gives consumers an opportunity to process work at a sustainable rate. It can also conceal a growing promise the service cannot fulfil. Queue depth is therefore neither a success metric nor an explanation on its own. A queue containing ten slow reports may represent more work than one containing a thousand small updates. A short queue of urgent requests can already be too old. The useful observation connects the backlog to service cost, completion capacity and the time beyond which the result loses its business value.

Microsoft's queue-based load-leveling pattern describes using a buffer to smooth demand and highlights the need to control downstream processing. The pattern changes when work is offered to the service; it does not manufacture throughput. That boundary is important when applying it to the hypothetical slowdown. If the consumer simply drains the queue as fast as possible whenever capacity returns, it can recreate the original surge. If autoscaling consumers increases pressure on a dependency that remains constrained, the queue has moved the overload rather than resolved it. The amount released from the buffer needs its own operating limit. [3]

The chart uses an intentionally simple fluid model. Original demand is eighty units of work per second. Processing capacity falls to sixty for the first one hundred and twenty seconds, then returns to one hundred. Each unit has the same assumed cost. The initial backlog is zero, storage has no limiting effect in this calculation, and no work expires or fails permanently. These assumptions make the arithmetic transparent. They do not describe the full behaviour of a real broker, database, network or application. The purpose is to show how an unchanged business workload can recover while an amplified attempt workload continues to fall behind.

With no extra attempt traffic admitted to this modelled queue, twenty units accumulate each second during the slowdown. After two minutes the backlog is two thousand four hundred. Once capacity returns to one hundred while new demand remains eighty, the service has twenty units of spare processing capacity per second. Clearing the backlog therefore takes another two minutes. The queue is empty at two hundred and forty seconds from the start. Recovery does not happen at the instant capacity returns: the service first has to repay the work it accepted while it was slower than its arrivals.

Now add an assumed forty attempt-units per second throughout the displayed interval. This is a sensitivity case, not a prediction of a particular retry algorithm. Arrivals become one hundred and twenty against sixty during the slowdown, so seven thousand two hundred units accumulate by the two-minute point. After capacity returns to one hundred, arrivals still exceed completions by twenty. At six minutes the backlog has reached twelve thousand instead of draining. The extra demand in this comparison is held constant to isolate its effect. A real retry population changes with deadlines, backoff, successful completions and the controls the application applies.

The two traces are calculated from the same rule: backlog cannot be negative, and it changes with admitted work minus completed work. Their different outcomes do not prove that every retry is harmful. A well-chosen attempt after a brief independent failure can recover a valuable task. The traces show why an attempt needs to be evaluated against available capacity. When the constrained service cannot process the additional load, more persistence can lengthen the period in which nobody receives a timely outcome. Reducing extra traffic can be a recovery action even while the underlying dependency is still being repaired.

The distinction between offered and admitted load is essential. A limiter may see a large number of requests but permit only some to enter the work queue. Rejected attempts still cost something at the boundary, so the admission path must be inexpensive enough to operate under pressure. They should not perform the same costly dependency call merely to decide whether to reject it. At the same time, a cheap rejection is not a completed customer task. The service should observe demand, admissions, rejections and useful completions separately so that an apparent reduction in queue growth is not mistaken for successful fulfilment.

Queue age adds the missing time dimension. Suppose a particular report is useful only before a decision meeting. Processing it after the meeting may have little value, even if the system eventually reports success. Keeping that work indefinitely can delay newer tasks that still matter. Expiry must be a business decision with a visible outcome, however, rather than silently deleting work to improve a chart. The caller needs to know whether the request was accepted for completion, declined, superseded or allowed to expire. A stable queue achieved by abandoning its contract is not a recovered service.

The same reasoning complicates priority. Giving urgent tasks precedence can protect important outcomes, but a permanent stream of urgent work can starve everything else. Fairness between tenants, operations and workload classes needs an explicit policy. A single global first-in-first-out queue may be easy to operate while providing poor isolation. Many small queues can improve separation while increasing monitoring and scheduling complexity. The useful choice depends on which parties share a scarce resource and which promises the organisation can defend when the total demand cannot be served immediately.

4. Build a boundary the overload cannot borrow through

The isometric view separates four concerns that are often compressed into one service box: admission, waiting, active execution and the downstream dependency. Each layer has a different scarce resource. The admission path must make a quick decision. The buffer has finite storage and an age distribution. Workers consume memory, connection slots and execution time. The dependency has its own capacity and permission boundary. Making those layers visible helps explain why increasing the worker count is not equivalent to increasing the whole service's capacity. A limit at one layer can be defeated when the next layer borrows from an unbounded shared pool.

Take a worker that limits itself to a modest number of active jobs but allows each job to open many concurrent downstream calls. The top-level limit appears responsible, yet the resource that matters is being multiplied underneath it. The same problem occurs when a timeout releases an application-level permit before the underlying operation has actually stopped consuming the dependency. The limiter is counting one thing while the resource is paying for another. The design should identify the point at which a permit is acquired, the work it covers and the observation that justifies releasing it.

Isolation is useful because unrelated work should not lose all of its capacity to the slowest dependency. Separate pools or concurrency allowances can keep a failing integration from occupying the resources needed by a healthy one. This is not free. Partitions can leave capacity idle while another partition is busy, and too many partitions can make the system hard to tune. The value is a more predictable failure boundary. The choice should be explained in terms of which workloads may affect one another, rather than presenting bulkheads as a universal instruction to create a separate queue and thread pool for every function.

A circuit breaker makes a different decision from a retry policy. It can temporarily stop attempts to a resource that is sufficiently likely to fail and allow controlled probes to assess recovery. Microsoft's pattern describes that separation. For the hypothetical service, the interesting question is what happens around the breaker: whether blocked attempts consume a retry budget, whether fallback work uses the same failing dependency, and whether the probe population remains bounded across all instances. A breaker drawn in an architecture diagram does not by itself establish those surrounding behaviours. [4]

A fallback can accidentally make the situation worse. If a cache miss sends every request to the original dependency, an apparently resilient cache path can concentrate load during a period of poor hit rate. If an alternate provider has a lower quota, switching all callers at once can transfer the incident. If a degraded answer is expensive to compute, it may not preserve enough capacity to be useful. A fallback should be evaluated as another workload with its own dependencies and correctness conditions. Its name is not evidence that it is cheaper, safer or available at the scale of the failed primary path.

There are also tasks for which stale information is unacceptable. Returning an older informational result with a visible timestamp can be a reasonable degradation for some readers. Using an old authorisation decision or presenting an outdated business state as current can be a different risk. The application needs to decide which parts of the result can degrade, how that condition is communicated and which operations must be refused. Preserving availability by hiding uncertainty can damage the business even when it makes the error-rate dashboard look better. The failure response should preserve a truthful account of what the service knows.

Google's treatment of overload discusses degraded responses and the need to reject work when even a reduced response cannot be served. That provides useful context for a design choice that can otherwise sound defeatist: declining some requests can protect the ability to complete others. It does not choose the business priorities for the hypothetical service. Those priorities require an explicit contract about which tasks may wait, which may degrade and which should fail quickly. The technical mechanism then needs to enforce that contract rather than merely record it in a document. [5]

5. Backoff changes timing; jitter changes company

Two clients can have individually sensible delays and still arrive together. If a large population fails at the same moment and every member waits the same interval, its next wave can remain synchronised. A growing delay changes the spacing between waves without necessarily dispersing the members of each wave. Jitter introduces variation into their timing. The important idea is not randomness as a decorative addition to a formula. It is avoiding a recovery population that repeatedly presents itself as one coordinated burst. The required distribution and bounds should fit the protocol, deadlines and observed workload.

The AWS discussion of exponential backoff and jitter illustrates why deterministic retry timing can leave clusters of work. That supports the timing mechanism, not a universal parameter choice for another service. In the hypothetical application, a longer random delay might distribute attempts but also push some beyond the caller's useful deadline. A shorter range might fit the deadline while doing too little to reduce synchronisation. The design needs both constraints. It should not treat a chosen algorithm name as proof that every generated delay is appropriate for the task. [6]

A retry loop also needs an interpretation of the response. An authentication failure, a rejected business rule and a temporary capacity limit do not ask for the same behaviour. Repeating an unchanged invalid request usually cannot repair the information that made it invalid. A throttling response may provide timing guidance, but the caller still needs to respect its own deadline and aggregate allowance. A connection failure may leave execution uncertain. The classification should lead to a decision about the operation, not just a lookup that assigns every exception another number of attempts.

The attempt schedule should include the time spent doing useful work, waiting for a response and waiting before another attempt. A policy can look short when its delays are listed separately yet exceed the task's entire time allowance once execution is included. It should also account for overlapping attempts if the application permits them. Parallel speculation can sometimes reduce latency, but it spends additional capacity to do so. Under overload that trade-off can be particularly expensive. An organisation should know when the service is making that choice, which operations qualify and what stops the extra work.

The schedule is not the only source of synchronisation. Periodic polling, token refresh, scheduled batch starts and a fleet of processes restarting after a shared event can all concentrate activity. The hypothetical outage could therefore recur even after the explicit retry loop is improved. The useful investigation asks which clocks are shared across the workload and which expensive actions they trigger. Spreading background work may help, but deadlines, business hours and external service windows can constrain that freedom. A correct solution changes the relevant arrival pattern while retaining the purpose of the scheduled task.

The caller who presses the button again

People can be another retry layer. A screen that spins without explaining whether a request was accepted invites resubmission. A disabled button may reduce accidental duplicates but cannot establish the server's state after a lost response. A durable operation reference and a clear status view can give the reader a way to inspect the first request instead of creating another one. The interface should distinguish waiting for an accepted operation from asking the server to start a new operation. That distinction becomes especially valuable when a short interactive deadline sits in front of a longer asynchronous process.

The wording matters because the software is making a promise. Saying that a request failed when its outcome is unknown encourages a different action from saying that processing was accepted and its status is being checked. Neither message should claim certainty the system does not possess. The status view must also avoid becoming an uncontrolled polling source during the incident. Choosing the interval, caching the status where appropriate and limiting repeated refreshes are part of the same capacity design. A useful user experience helps people recover their intention without turning their uncertainty into another wave of work.

6. Recovery traffic needs a route home

A queue-driven service introduces another distinction: successful processing and successful acknowledgement are separate events. The business effect may complete before the broker learns that the message can be removed. If the acknowledgement is lost, the system can see the message again. Azure Service Bus documents transfers, locks and settlement as separate parts of delivery. The architectural consequence is to connect the message's processing identity to the business operation and handle repeated delivery deliberately. Increasing the delivery count threshold does not establish that repeated execution is safe. [7]

The worker also needs to recognise work that will not become valid through repetition. A malformed payload, an unsupported operation version or a permanently missing prerequisite may require correction or investigation. Returning it indefinitely to the active queue can spend capacity without improving the chance of success. A separate failure path can keep the ordinary workload moving, but that path needs an owner and a visible consequence. A dead-letter queue whose contents are never examined is not a recovery strategy; it is an accumulation of unresolved promises that happens to be outside the main throughput chart.

Microsoft's Service Bus dead-letter documentation explains the role of the secondary subqueue and the need for applications to deal with its messages. The important choice for the hypothetical service is what happens before any resubmission. The team needs to establish whether the underlying defect was corrected, whether the original business intention is still current, and whether an earlier attempt already caused an effect. A bulk replay that skips those questions can convert old uncertainty into fresh load. The recovery procedure should be capable of selecting work, rather than treating every stored message as equally safe to run again. [8]

When capacity returns, live demand and historical recovery work compete. A service that drains all old tasks at the maximum available rate may give current users a second outage. A service that reserves everything for new work may never clear the backlog. The release rate for recovery work therefore needs a policy tied to actual spare capacity and business priority. It can be adjusted as the dependency's behaviour changes. The essential point is that recovery is a workload in its own right, not a special category exempt from the limits applied to ordinary traffic.

The recovery decision also has a stopping condition. A replay may need to pause when latency rises, when the oldest live request exceeds its useful age, when duplicate detection finds an unexpected pattern or when a dependency starts throttling again. The relevant signals depend on the service. What matters is that the person or mechanism releasing old work can observe them and act before the buffer becomes the source of another surge. A replay command without a feedback path offers persistence, but little control over its consequences.

Preserving provenance makes that feedback more useful. An operation should be traceable across its first submission, later attempts, queue deliveries and any manual correction. The identifiers do not need to expose sensitive content to achieve this. They do need a stable relationship to the business intention and enough configuration context to explain the policy under which each attempt ran. Without that continuity, a team can spend its incident response deciding whether it is looking at one stubborn operation, many new requests or a mixture of both. The extra logging volume then becomes another resource pressure without delivering the needed understanding.

7. Look for the work that is getting done

A service can be busy, available and unhelpful at the same time. CPU, connection utilisation and request rate describe activity, while useful completions describe progress. Neither category replaces the other. The interesting observation is how they diverge. If attempts rise while unique completed operations fall, the service may be spending more to achieve less. If latency improves only because a larger fraction of work is rejected, the application may have protected its resources while still failing many readers. The operating view should make both facts visible rather than choosing whichever metric tells the more reassuring story.

The denominator is particularly important for an application that retries. An attempt-level success rate can be distorted by the number of attempts per operation. A user-level completion rate can hide the amount of resource consumption required to produce each success. A useful dashboard separates original demand, total attempts, admitted work, unique completed operations, time to useful completion and outcomes that remain uncertain. It also shows age and workload class where those distinctions affect the decision. These measures describe different questions; collecting them is useful only when the team can connect a change in them to an action.

One diagnostic ratio is attempted dependency calls per original operation. Another is the share of scarce execution time spent on operations whose initiating deadline has already expired. Neither should be treated as a universal service-level objective. They are ways to make a suspected mechanism visible. The definition needs to be precise enough to avoid counting harmless connection recovery as an extra business execution or treating an intentionally asynchronous task as abandoned work. The measure is valuable when it discriminates between explanations, not when it provides another attractive line on the incident dashboard.

Cost is part of that observation. The extra attempts may increase request charges, logging volume, connection churn or compute consumption even when they do not complete more business work. A per-request cost can appear to improve if the denominator grows with retries, while the cost per useful outcome deteriorates. The organisation needs a cost view that follows the task far enough to include failed and repeated effort. No savings are claimed here. The point is to choose an accounting boundary that would reveal whether a proposed resilience change reduces waste rather than simply moving it to another service or invoice.

Test the chain, not only the loop

A successful retry in a unit test establishes very little about a fleet under correlated failure. A more revealing controlled test changes a dependency's latency or completion capacity while keeping original demand identifiable. It observes whether attempt amplification remains bounded, whether deadlines end work as intended and whether useful throughput recovers after the disturbance. The environment and limits should make that test safe. The objective is not to cause an uncontrolled production incident in order to demonstrate toughness. It is to challenge the specific assumption that extra attempts remain helpful when many callers fail together.

The scenarios should distinguish slow responses, definite rejections and unknown outcomes. They should include a dependency that recovers before the caller's deadline and one that does not. A queue-based service should also exercise acknowledgement uncertainty, expired work and a deliberately constrained replay. The expected result is not simply that every submitted task eventually succeeds. Some tasks should be declined or stop trying. The meaningful question is whether the observed outcome matches the contract, while the constrained resource remains protected and the organisation can explain what happened to each class of work.

A comparison needs the same original demand. Otherwise, a configuration that appears to recover faster may merely have received an easier workload. The account should retain the arrival pattern, task mix, dependency condition and configuration versions relevant to the result. It should distinguish calculated examples such as the chart in this article from measurements obtained in a running test. Repeating a plausible numerical story as if it were a benchmark would weaken the evidence. A transparent small model is useful because its assumptions can be challenged, not because its smooth lines resemble a production trace.

8. The system that is allowed to stop trying

Return to the first delayed request. It did not have to become an outage. The failure chain acquired its force through several transitions: a timeout was interpreted as permission to start more work; layers multiplied attempts without a common budget; waiting work concealed a widening capacity gap; and recovery traffic was treated as if its urgency created additional throughput. Each transition offers a place to interrupt the chain. The design does not need every possible resilience pattern. It needs controls at the points where this service can turn uncertainty into extra load or a repeated business effect.

There are circumstances in which another attempt is exactly the right response. A brief independent failure may disappear, a safe read may complete quickly on another route, or a bounded resubmission may recover a valuable task. The argument is not against persistence. It is for persistence that remains accountable to time, capacity and the meaning of the operation. A service should be able to explain why an attempt was made, which allowance paid for it and what observation would prevent the next one. That explanation is more useful than a generic statement that retries have been enabled for reliability.

The most important recovery capability may therefore be the ability to stop. Stop creating attempts when the deadline has made their result useless. Stop borrowing capacity from unrelated work. Stop replaying a backlog when the live service begins to suffer. Stop claiming definite failure when the execution outcome is still unknown. These are different decisions, and each needs an appropriate owner or mechanism. Together they make room for the underlying dependency to recover and for the organisation to correct the work that remains, instead of forcing every unresolved intention back through the same overloaded path.

A dependable service does not promise to try forever. It makes a more practical promise: accepted work has a defined meaning, additional effort has a limit, and a failure produces an outcome that people can understand and act on. When those conditions hold, retries can remain a useful tool rather than becoming an invisible workload with no accountable customer. The difference appears most clearly during recovery. As the original fault recedes, the system has enough control over its own behaviour to let useful work resume.