Explore architecture decisions, durable patterns and technology developments. Each article connects a concept to a question you can ask in a real project.
The OpenAI–NASK research partnership signals a closer focus on AI safety. What does it mean for enterprise architects, system assurance, agent permissions and verifiable security evidence?
Read the article →New to ArchitectMentor? Begin with Practice: make a decision before reading the analysis, then follow the links only if you want to go deeper.
Work through a scenario, answer a mentor question, then compare your reasoning with a senior architect.
Try an exercise →02 · LEARNC4, ADR, resilience patterns and frameworks explained through the decisions they support.
Explore foundations →03 · FOLLOW CHANGEDates and primary sources, followed by an interpretation and a practical question.
Browse articles →04 · DESIGNDraft an ADR locally, or turn a brief into an HLD outline for review.
Open the tools →Enter a term. Search covers the English edition: titles, descriptions and topics.
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…
A six-field operational contract: owner, blast radius, fallback, shutdown trigger, propagation time and removal date.
HTTP 200 is not evidence of a state change. Three options, transactional outbox and five audit acceptance tests.
An evidence ladder from liveness and readiness through work progress to a measurable end-to-end outcome.
How 3 × 3 attempts amplify load and how to establish one retry owner, a shared deadline and 429/503 tests.
From measurable demand and data freshness to a choice: optimise, read replica or failover.
Six fields for each condition: criterion, owner, evidence, verifier, gate and failure action.
Seven review areas and a responsibility → requirement → evidence matrix.
Why an optional field can still break a client, and how to verify source, wire and semantic compatibility.
Durably record auxiliary work, retry the right step and avoid duplicating the business operation.
Check compatibility and scale the review to the actual change.
Safe retries and decisions when an operation has an unknown outcome.
When optional-feature failure should not block a result, and where the boundary lies.
Carry trusted tenant context through authorisation, data, caches, search and asynchronous work.
Separate acceptable data loss from recovery time and measure both across the complete user journey.
Turn “fast, secure and easy to change” into a testable requirement that guides an architecture decision.
Define an SLI for a user journey, calculate an error budget and use it to guide an architecture decision.
The bulkhead pattern: failure boundaries, separate resource limits and their trade-offs.
Goals, stakeholders, scenarios and quality concerns as the starting point for an architecture description.
Context, containers, components and code: which views support a decision?
Record the context, decision, alternatives and consequences in an ADR.
Where ISO 42010, TOGAF, ArchiMate, C4 and ADR can help.
Retry, circuit breaker and transactional outbox in the context of risk and cost.
A short checklist for discussing goals, facts, risk and validation.
Separate ownership of the authoritative outcome, reconciliation, and unresolved operational exceptions.
Would you classify the service as available? In 2–3 sentences state its boundary, the signals and controlled test you need, and what would change your decision.
Distinguish vendor implementation details from information needed to assess responsibility, risk and SaaS integration.
Distinguish an additive schema change from compatibility of running consumers and plan evidence before rollout.
Separate the business outcome from failure of an auxiliary notification.
Understand the impact before treating a change as a hardware swap.
Distinguish a missing response from a failed operation.
Preserve the core function when an optional feature fails.
Where did tenant isolation break? How will you change authorisation, the cache key and tests so the fix covers the whole path rather than this endpoint alone?
What must be restored and checked before you resume submissions? How will you verify a five-minute RPO and 30-minute RTO for the whole service?
How do you split this change into safe stages? When may writes to the old field stop, when may the field be removed, and how do you test rollback?
How will you stop reports from affecting checkout? What limits, overload behaviour and measurements will you define before changing the connection count?
How do you separate requirements compliance from the decision to keep evaluating the offer? What would you recommend, and what evidence is needed before approving the implementation architecture?
How will you make retries safe and avoid starting a second charge? What happens when the first call has an unknown outcome?
Why can this happen? How would you make the database change and event publication reliable? Why does swapping their order not solve it?
A team aggregates component health checks into availability while accepted work never reaches its terminal state.
An API and SLA do not resolve data, IAM, continuity, operations and exit questions.
A team treats an additive schema change as safe without running supported consumers or checking contract behaviour.
Failure of an auxiliary email makes a successfully committed order look failed and encourages the user to create a duplicate.
The gateway validates a token, while downstream layers assume that an authenticated user may access any referenced resource.
A green backup report does not prove the entire service can return within its recovery target.
Code, data backfill and removal of the old contract ship together, preventing version coexistence and leaving rollback with an incompatible schema.
A slow reporting service consumes shared workers and prevents orders from completing.
A quick integration becomes the target architecture when no owner, contract or migration trigger is recorded.
Direct access turns internal tables into an unversioned API and bypasses the data owner’s rules.
Services share a database and deploy together, adding network costs without independent change.
The OpenAI–NASK research partnership signals a closer focus on AI safety. What does it mean for enterprise architects, system assurance, agent permissions and verifiable security evidence?
The newly disclosed CVE-2026-98432 vulnerability concerns the support of TCP/IPv4 connections in the Linux kernel and can lead to system failure, memory violation, and under certain conditions even to remote code execution. The problem…
On 28 October 2026, GitHub announced a shared compute entitlement spanning certain GitHub Actions workloads and Copilot cloud sandboxes. This is more than a billing change: agent experiments can consume capacity from the same allowance…
The 14 October public preview pins actions and their dependencies to commits, but still needs an update process and review of the diff.
The 1 March 2028 deadline, two migration paths and evidence before moving traffic.
A longer installation token can expose storage, proxy and redaction limits. Verify integrations without exposing secrets.
The 2 November retirement and October brownouts call for testing the full build, signing and publication chain.
The 30 September change improves transfer integrity, with limits for range reads and composite uploads.
The 29 September Public Preview adds SSE, WebSockets and gRPC streaming, with migration and domain constraints to weigh.
Which features were removed from PostgreSQL 19 Beta 4, and what does that mean for a migration decision?
Stable Kubernetes attributes and the migration questions behind consistent telemetry.
Why an internal platform needs clear ownership and interfaces alongside templates.
What stable TCPRoute and UDPRoute mean for Kubernetes network design.
Action gateway, independent authorisation, human approval and audit for AI agents.
Tutorial 02: source register, visible unknowns, design-changing questions and statement verification.
Tutorial: from a brief and questions to a failure case, a diagram, verification and an ADR.
2 materials. Each material connects a concrete situation with a decision you can verify.
Choose a quick answer with an explanation, or develop your reasoning with the mentor. Easy and intermediate practice scenarios.
Separate ownership of the authoritative outcome, reconciliation, and unresolved operational exceptions.
Try this decision →Distinguish vendor implementation details from information needed to assess responsibility, risk and SaaS integration.
Try this decision →Distinguish an additive schema change from compatibility of running consumers and plan evidence before rollout.
Try this decision →Separate the business outcome from failure of an auxiliary notification.
Try this decision →Understand the impact before treating a change as a hardware swap.
Try this decision →Distinguish a missing response from a failed operation.
Try this decision →Preserve the core function when an optional feature fails.
Try this decision →The bulkhead pattern: failure boundaries, separate resource limits and their trade-offs.
Read the article →ArchitectMentor is an independent learning initiative helping people practise architecture decisions. Founded by Wiesław Ejsymont, it is designed to welcome more experts over time.
Discover ArchitectMentor →From a brief to a reviewed decision: assumptions, alternatives, diagrams and evidence.
Explore the tutorials →Selected events with programme details, participation terms and a comment on their value for architects.
See the selection →