Choose an area or find a topic. Each group lists the newest articles first.
Matching articles: 24
No matching articles. Try another term or area.
In a fictional distributed system, a request times out even though the operation may have committed. How do we detect ambiguous outcomes, prevent duplicate effects and escalate cases that cannot be resolved automatically? An architecture…
Read →Why an optional field can still break a client, and how to verify source, wire and semantic compatibility.
Read →Durably record auxiliary work, retry the right step and avoid duplicating the business operation.
Read →Safe retries and decisions when an operation has an unknown outcome.
Read →Retry, circuit breaker and transactional outbox in the context of risk and cost.
Read →A six-field operational contract: owner, blast radius, fallback, shutdown trigger, propagation time and removal date.
Read →How 3 × 3 attempts amplify load and how to establish one retry owner, a shared deadline and 429/503 tests.
Read →When optional-feature failure should not block a result, and where the boundary lies.
Read →Separate acceptable data loss from recovery time and measure both across the complete user journey.
Read →The bulkhead pattern: failure boundaries, separate resource limits and their trade-offs.
Read →HTTP 200 is not evidence of a state change. Three options, transactional outbox and five audit acceptance tests.
Read →Carry trusted tenant context through authorisation, data, caches, search and asynchronous work.
Read →An evidence ladder from liveness and readiness through work progress to a measurable end-to-end outcome.
Read →Turn “fast, secure and easy to change” into a testable requirement that guides an architecture decision.
Read →Define an SLI for a user journey, calculate an error budget and use it to guide an architecture decision.
Read →From measurable demand and data freshness to a choice: optimise, read replica or failover.
Read →Six fields for each condition: criterion, owner, evidence, verifier, gate and failure action.
Read →Seven review areas and a responsibility → requirement → evidence matrix.
Read →Check compatibility and scale the review to the actual change.
Read →Record the context, decision, alternatives and consequences in an ADR.
Read →A short checklist for discussing goals, facts, risk and validation.
Read →Goals, stakeholders, scenarios and quality concerns as the starting point for an architecture description.
Read →Context, containers, components and code: which views support a decision?
Read →Where ISO 42010, TOGAF, ArchiMate, C4 and ADR can help.
Read →