Resilience & cloud-native patterns

The four sections describe different layers of the same system, and most patterns show up in more than one of them under a different role. ### Around a single call The resilience patterns stack around each outbound call. A timeout is the innermost limit; retries wrap it; a circuit breaker decides whether to attempt the call at all; a bulkhead caps how much of the caller the call may occupy; a fallback decides what to return when everything inside has given up. Throttling and load leveling sit at the other end of the same call, protecting the service that receives it. [Health endpoints](/topics/found-cloud-design-patterns-health-monitoring) are what the platform and load balancer read to decide whether an instance receives traffic or gets restarted, so they belong to the same conversation about failure. ### Across the queue The queue in [load leveling](/topics/found-cloud-design-patterns-load-leveling) is the same queue that [competing consumers](/topics/found-cloud-design-patterns-competing-consumers) drain, that a priority scheme splits, and that asynchronous request-reply exposes to a client. The [saga](/topics/found-cloud-design-patterns-saga) builds on all of this: it needs reliable messaging between steps, idempotent participants, and the compensation idea from the core ideas above. The data section feeds on messaging too, since a CQRS read model is a materialized view kept current by events, and a claim check pairs a queue with storage because the payload does not fit the message. ### Around the whole deployment Gateway offloading and the sidecar or ambassador answer the same question from two placements: one shared component at the edge, or one helper beside each instance. An ambassador is also a natural home for the retries and breakers from the resilience section. Deployment stamps and geodes apply the sharding idea to entire deployments rather than rows. External configuration and feature flags are the runtime switches that fallbacks, kill switches and gradual rollouts rely on.

The same handful of choices recurs across all four sections. Naming the one you are making, and what would change your mind, is usually worth more than the pattern's name. - **Fail fast versus keep trying.** Retries recover from transient faults; breakers, deadlines and load shedding give up early to protect the caller and the dependency. The deciding facts are whether the fault will likely clear within the caller's budget and whether the operation is safe to repeat. - **Freshness versus load.** Caches, views and replicas cut read cost by serving data that may be behind. The question is how stale a given screen or decision can tolerate, and whether you bound it by expiry, by invalidation on write, or both. - **Synchronous versus asynchronous.** A direct call gives the caller an immediate, simple answer and couples its availability to the dependency. A queue decouples them and absorbs bursts, at the price of duplicates, ordering limits and a separate path for reporting results. - **Centralised versus per-instance.** A gateway applies a policy once at the edge; a sidecar applies it beside every instance. An edge policy is easier to reason about and becomes a shared bottleneck; a per-instance one scales with the fleet and multiplies what has to be deployed and upgraded. - **Isolation versus utilisation.** Separate pools, shards, stamps and machines contain failures and noisy neighbours; consolidation raises utilisation and lowers cost. Security boundaries, very different scaling profiles and the acceptable blast radius decide where to stop consolidating.

Several shapes recur across the sections under different names; recognising one is often how you place an unfamiliar question. - **Bound the damage.** Timeouts bound time, bulkheads bound concurrency, quotas bound resources, stamps bound blast radius. - **Send a pointer, not the payload.** Claim check, valet key and index table all move a small reference through the constrained path and keep the heavy data, or the heavy access, somewhere better suited to it. - **Precompute for the read.** Cache-aside, materialized views and CQRS read models all trade write-time or background work for cheap reads, and all inherit the same staleness and rebuild questions. - **Put a proxy in the path.** Gateway routing, aggregation and offloading, the ambassador, the gatekeeper and the anti-corruption layer each place a component between two parties to translate, protect or simplify the conversation. - **Buffer, then drain at your own pace.** Load leveling, competing consumers, priority queues and asynchronous request-reply share one structure: accept work quickly, store it, and process it at the rate the back end can sustain. - **Split by key into independent units.** Sharding splits rows, bulkheads split resource pools, deployment stamps and geodes split whole deployments. The recurring questions are the key, uneven load, and requests that span units. - **Decide at runtime, not at build time.** External configuration and feature flags turn values and behaviour into data that can change without a redeploy, which is powerful and is also a new way to break a running fleet.