Search the practice set
126 questions, 454 terms and 400 topics in 20 areas.
60 results for “Writing Decision Records”
Architecture Decision Log
The ordered, immutable collection of a system's decision records, read as a history rather than as a specification.
Offset Management
How a consumer records its position in a stream, and the decision that determines whether processing is at-least-once or at-most-once.
Re-architect vs Rebuild
Restructuring an existing system incrementally versus writing a replacement from scratch — and the strong evidence that incremental wins.
Architecture Decision Record
A short, immutable document capturing one architectural decision, its context, the alternatives, and its consequences.
Decision-Making Under Uncertainty
Choosing well when the information is incomplete — by bounding the downside and buying information, rather than by waiting for certainty.
Reversible Decision
A choice that can be undone cheaply, and which therefore deserves far less deliberation than an irreversible one.
Architecture Trade-off Analysis Method
A structured evaluation that scores an architecture against prioritised quality-attribute scenarios and identifies the points where those attributes conflict.
Atomic Commit Protocol
Any protocol ensuring that several participants reach the same decision to commit or abort — and a problem provably unsolvable with certainty in an asynchronous system with failures.
Build vs Buy
The choice between developing a capability in-house and acquiring it, decided on differentiation and total cost rather than on feature lists.
Database per Service
Each service owning its own datastore, with no other service reading or writing it directly.
Delivery vs Maintainability
Choosing where to take deliberate shortcuts, based on which kinds of debt are cheap to repay and which compound.
Denormalisation
Deliberately duplicating data across records to make reads cheap, accepting the write-time cost of keeping copies in step.
Dual Write
Writing the same change to both the old and new stores during a migration, and the reconciliation that makes it trustworthy.
Horizontal vs Vertical Scaling
Adding more machines versus making one machine bigger — and the fact that vertical is underrated for stateful tiers.
Managed vs Self-Managed
Trading control, portability and unit cost against the operational burden of running the thing yourself.
Monolith vs Microservices
A trade of deployment independence against distributed-systems complexity, decided by team topology far more often than by technology.
Multi-Cloud
Deliberately running across more than one cloud provider — a decision with a much higher cost than the lock-in it is usually adopted to avoid.
Outbox Pattern
Writing an outgoing message into a table in the same transaction as the business change, and relaying it to the broker separately, so the two cannot diverge.
Presenting to Executives
Leading with the decision and the business consequence, at a level of abstraction where technology names do not appear.
Provisioned vs Serverless Capacity
Paying for a fixed database size continuously, versus paying for capacity consumed with automatic scaling — a crossover decision driven by duty cycle.
SQL vs NoSQL
A choice driven by access patterns, consistency requirements and query flexibility — not by data volume, which is the reason usually given.
Security vs Usability
A trade-off that is usually resolved by varying the control with the value of the action, rather than by choosing a uniform level of friction.
Strong vs Eventual Consistency
A per-operation decision, not a per-system one: whether this specific read must reflect every completed write.
Structured Logging
Emitting log entries as machine-parseable key-value records rather than as formatted prose.
A multi-tenant SaaS product has outgrown one database. You must shard. How do you choose the partition key, and what makes this decision so expensive to get wrong?
What the interviewer is testing Whether you exhaust cheaper options first, and whether you understand that a shard key is close to irreversible. First: do not s
Choose storage for four workloads: a Postgres data directory, user-uploaded images, a shared build cache, and seven years of audit records.
Postgres data directory — block storage It needs low latency random reads and writes and a filesystem, and it attaches to one instance. That is precisely block
Prime Video reported a 90% cost cut by consolidating a serverless distributed service into one process. Does that mean microservices were the wrong choice, and what is the actual decision rule?
What actually happened The Prime Video Video Quality Analysis team's 2023 post describes an audio/video monitoring service built as Step Functions orchestrating
When is an architectural decision worth an ADR, and what makes an ADR useful two years later?
What the interviewer is testing Whether you document decisions as a habit, and whether you know that most documentation fails because it records the wrong thing
A team wants event sourcing for a new order service, citing audit requirements. What do you recommend?
The recommendation: probably an audit log, not event sourcing If the requirement is audit , event sourcing is a very expensive way to obtain it. An append only
A team wants to build a new internal API on serverless functions. It will serve steady traffic of about 200 requests per second during business hours. What do you advise?
What the interviewer is testing Whether you can apply the serverless trade off to a specific workload rather than treating it as a default good or a default bad
A team wants to move a workload from PostgreSQL to a document store because "the schema keeps changing". What do you ask?
The questions 1. What is actually changing — the shape, or the schema management process? "The schema keeps changing" usually means migrations are painful, not
Four services want four different databases: Postgres, MongoDB, Cassandra and Neo4j. What do you say?
The response: make each team justify it against a default Polyglot persistence is legitimate and routinely over applied. The question for each is not "is this d
Netflix built its own CDN; Dropbox moved storage off S3. Both are usually wrong. What conditions made them right, and how do you test for those conditions?
What the interviewer is testing Whether you can extract the conditions from a famous decision rather than the decision itself. These two cases are the most comm
Security wants mandatory hardware keys for every login; the business says it will cost conversions. How do you resolve it architecturally rather than by picking a side?
What the interviewer is testing Whether you treat security as a fixed dial to be turned up, or as a risk proportionate design variable. Both stated positions ar
Writing Decision Records
Context, alternatives and consequences, written once and never edited.
Architecture Decision Records
One decision, its context, alternatives and consequences, kept immutable.
Architecture Decision-Making
General material on making and recording architectural decisions.
Decision Practice
Thresholds, review, supersession and keeping the log alive.
Auditability
Tamper-evident, attributed records that survive async boundaries.
Authorization
RBAC, ABAC and ReBAC, and centralising the decision but not the enforcement.
Build vs Buy
Differentiation, five-year TCO, and the exit cost of each option.
CQRS
Separate models for writing and reading, each optimised for its job.
Centralised vs Distributed
Shared platform leverage against team autonomy.
Deciding Under Uncertainty
Bounding the downside and buying information cheaply.
Delivery vs Maintainability
Fast in the cheap places, careful in the expensive ones.
Facilitation
Running a design session that reaches a decision.
Managed vs Self-Managed
Trading control and unit cost against operational attention.
Monolith vs Microservices
A team-topology decision far more often than a technology one.
Performance vs Cost
Buying latency, and knowing what the last millisecond is worth.
Presentation Skills
Structure, pacing and the slide that carries the decision.
Presenting to Executives
Decision first, cost, risk, and what happens if we do nothing.
Reliability vs Complexity
Mechanisms that add availability and add failure modes.
Reversibility
One-way and two-way doors, and buying optionality deliberately.
SQL vs NoSQL
Decided by access patterns and query flexibility, not by data volume.
Security vs Usability
Varying control by the value of the action rather than uniformly.
Serverless vs Containers
Spiky and event-driven versus sustained throughput.
Single vs Multi-Region
Driven by RTO, RPO and residency rather than by ambition.
Strong vs Eventual Consistency
A per-operation decision, resolved by what a stale read would cost.
Sync vs Async
Whether the caller's outcome depends on the callee's response.