Patterns
Application-Layer Sharding
throughput
Seen in 3 articles across 3 companies
Application-layer sharding moves the decision of where data lives — which shard, which cluster, which storage node — into the application code that reads and writes the data, rather than relying on the underlying storage system's internal sharding. The application knows which tenant or entity each piece of data belongs to and uses that knowledge to route reads and writes deterministically. The underlying storage system sees only the operations it's told to perform; it doesn't make routing decisions on the application's behalf.
Atomic Phases
resilience
Seen in 1 article across 1 company
Break a long workflow into discrete, individually committable phases so that any interruption resumes from the last committed boundary without redoing or skipping work.
Batched Routing by Destination
throughput
Seen in 1 article across 1 company
Batched routing by destination is a strategy for issuing bulk operations against partitioned downstream systems without paying the fanout cost of cross-partition batches. Incoming items arrive in an interleaved stream (orders by region, log lines by service, messages by tenant); a routing layer groups items by their downstream destination (database shard, search cluster, partition, node) and issues each bulk operation against a single destination. The result: each bulk operation has a narrow fault domain, single-destination failures no longer cause widespread batch failures, and the downstream system can apply per-destination optimizations.
Cell Architecture
resilience
Seen in 2 articles across 2 companies
Cell architecture organizes a distributed system as a set of independent, self-contained units (cells), each of which can fully serve a subset of the workload on its own. Cells share no critical state with each other; a failure in one cell does not propagate to others. Capacity scaling happens by adding cells rather than by growing individual cells beyond their designed size. Each cell typically combines multiple infrastructure components (compute, storage, queueing, routing) into a complete service unit, and is sized small enough to be operationally manageable as a single coherent system.
Checkpoint-Bounded Scans
performance
Seen in 1 article across 1 company
When background machinery repeatedly scans a table by a monotonic column — 'everything with timestamp ≤ now' — maintain a persistent checkpoint of the last position processed and bound every scan from below as well as above. The unbounded form forces the storage engine to consider every pending row on every pass (in MVCC systems like MySQL, walking a history list that grows with backlog); the bounded form touches only the increment since the last pass, keeping scan cost proportional to progress rather than to backlog depth.
Circuit Breaker
resilience
Seen in 2 articles across 2 companies
A circuit breaker wraps calls to a dependency and tracks their outcomes. While the dependency is healthy the breaker is closed and calls pass through. When failures cross a threshold — repeated timeouts or errors in a short window — the breaker opens: subsequent calls fail immediately, without attempting the dependency at all. After a cooling period the breaker lets a probe through (half-open); success closes the circuit again, failure re-opens it.
Circular Dependency Avoidance
resilience
Seen in 1 article across 1 company
A circular dependency in infrastructure exists when system A monitors or controls system B, but A itself depends on B to function. The dependency is invisible during normal operation — everything works — and only becomes visible when B fails: A loses its ability to detect or respond to B's failure at exactly the moment that ability matters most.
Compile-Time Boundary Enforcement
consistency
Seen in 1 article across 1 company
Declare an architectural boundary as data, then enforce it with automated checks that fail the build — or flag the violation in development — whenever code crosses it. The boundary becomes real the day it is declared, not the day the underlying systems are actually separated: developers hit violations at their desks, CI blocks new coupling from landing, and existing violations are converted into an explicit, annotated backlog that must reach zero before the physical separation can proceed.
Dead Man's Switch
observability
Seen in 1 article across 1 company
A Dead Man's Switch detects failure by monitoring the absence of an expected health signal, rather than by detecting the presence of a failure signal. A healthy system emits a continuous heartbeat — a periodic message, a regularly-updated timestamp, an always-firing alert rule, a successful liveness probe — and an external observer counts these heartbeats. When the heartbeat stops, the observer raises an alarm. Silence itself is the signal.
Durable Workflows
resilience
Seen in 2 articles across 2 companies
A durable workflow is a multi-step business process whose execution state survives crashes, restarts, and arbitrary waits — without the business logic needing to know about persistence, retries, or recovery. The workflow author writes linear code; the runtime guarantees that if execution is interrupted at any point, it resumes from the last known good state when restarted.
Embedded vs Centralized Orchestration
resilience
Seen in 2 articles across 2 companies
When a system needs cross-step coordination — workflows, sagas, retries, scheduling — there are two architectural shapes. The orchestration logic can live inside each participating service as a library (embedded), or in a dedicated cluster that every service talks to (centralized). The two shapes have inverse tradeoffs: embedding gives you isolation and operational simplicity at the cost of cross-service coordination; centralizing gives you cross-service coordination and uniform tooling at the cost of a shared dependency that becomes a single point of failure.
Fault Isolation
resilience
Seen in 6 articles across 6 companies
Fault isolation is the architectural practice of containing failures so that one component's degradation doesn't cascade into others. The defining mechanism is making explicit the boundaries between components and ensuring those boundaries hold under failure — through dedicated resources, separate data paths, independent failure domains, or sandbox-style containment.
Feedback-Controlled Load Management
throughput
Seen in 2 articles across 2 companies
Static limits are perpetually wrong. A fixed concurrency cap, queue timeout, or shed threshold encodes one moment's understanding of capacity into a number that traffic immediately outgrows or undershoots — too tight and the system rejects work it could handle; too loose and it melts before the limit triggers. Worse, static thresholds produce cliff behavior: the system is fully open until the instant it slams fully closed, and the synchronized rejections that follow seed retry storms that re-create the overload.
Generic Mitigation
resilience
Seen in 1 article across 1 company
Build mitigations that can be applied before the root cause is understood: actions that reduce impact for a broad class of failures, are safe to apply experimentally, and are cheap to reverse. A generic mitigation is judged on four properties — it acts fast relative to the availability budget, it introduces no user-visible errors of its own, it can be applied incrementally so recovery can be tested at small percentages, and it does not depend on resources inside the failure domain it mitigates.
Hibernation vs Polling
throughput
Seen in 1 article across 1 company
When a process needs to wait for an external signal — a callback, an approval, a scheduled time, a state change in another system — there are two ways to handle the wait. The naive approach is polling: a loop, a queue consumer, or a scheduled job that periodically wakes up and asks "is it ready yet?" The durable approach is hibernation: the process serializes its state, releases its compute resources, and exists only as data until an external signal explicitly wakes it.
Idempotency Keys
consistency
Seen in 3 articles across 3 companies
A client-supplied stable identifier that the server uses to deduplicate retries of the same logical operation. The first request creates a record of the outcome under the key; subsequent requests with the same key return that recorded outcome rather than re-executing the work. Same key in, same outcome out, regardless of how many times the request is sent.
Logical–Physical Migration Split
resilience
Seen in 2 articles across 2 companies
Split a high-risk storage or topology migration into two phases with different rollback costs. In the logical phase, the target topology is made real to every client — through views, routing rules, proxies, or flags — while the physical layout underneath stays unchanged; the system behaves, from the application's perspective, as if the migration had already happened. Because nothing has physically moved, rollback is a configuration change measured in seconds, and the new behavior can be ramped gradually under live production traffic. Only after the logical world has proven itself does the physical phase run: data actually moves, and the hard-to-reverse step executes against a topology that is no longer novel.
Priority-Aware Load Shedding
resilience
Seen in 2 articles across 2 companies
Priority-aware load shedding is the practice of dropping the lowest-value traffic first when a system is overloaded, rather than shedding requests uniformly. Every request carries a priority tag (often a small integer tier like t0-t5), and when admission limits are tightened, the system walks up the tier ladder from lowest to highest priority — only sacrificing higher tiers if pressure persists after lower tiers are fully shed.
Queue with Guaranteed Delivery
resilience
Seen in 2 articles across 2 companies
A queue with guaranteed delivery persists messages durably until they have been successfully consumed and acknowledged. The queue tolerates large backlogs, survives consumer failures, and does not drop messages under sustained pressure. The contract with producers is: once the queue acknowledges receipt, the message will eventually be delivered. The contract with consumers is: the message remains available (and potentially redelivered) until it's been processed and acknowledged.
Retry Budget
resilience
Seen in 1 article across 1 company
Bound retry amplification mechanically by giving each client a local budget — typically a token bucket — that retries spend. While tokens remain, transient failures are masked freely; when the bucket empties, retrying continues only at a fixed, low rate. The budget converts the retry storm from a behavioral risk (hoping clients back off enough) into an arithmetic bound: no client can more than marginally multiply its offered load, no matter how long the dependency stays down.
Retry with Backoff and Jitter
resilience
Seen in 2 articles across 2 companies
When a client retries a failed operation against a shared service, raw persistence is dangerous: the failure might be transient (retry soon and succeed) or systemic (the server is degraded, and every retry adds load at the worst possible moment). The client cannot tell which regime it is in. Exponential backoff resolves this without requiring the client to know — each successive failure waits proportionally longer (typically 2^n), so transient failures recover quickly while systemic failures see the retry rate collapse automatically.
Shard-Key Colocation
consistency
Seen in 2 articles across 2 companies
When sharding, place every row that must be read or committed together on the same shard, by two coordinated choices: shard the full set of tables that reference each other (not just the big one), and partition them all by the same key — the entity whose boundary matches the application's transaction and query patterns. Transactionality guarantees stop at a single host; colocation is how a sharded system keeps the transactions it actually needs without distributed coordination.