LEARN. PRACTICE. GROW.Concept and mechanism
System design begins with understanding users, their required outcomes, and what happens when the system fails. A technology list does not answer those questions. Identify critical operations, frequency, volume, deadlines, data, and external dependencies. Separate mandatory constraints from preferences and unconfirmed assumptions. A requirement such as fast needs a population, metric, threshold, and observation window. An SLI measures an aspect of service; an SLO defines the target for that measure. An SLA has its own contractual scope and should not be inferred automatically from an internal target. Design must expose the outcome experienced by users.
Guided application
In a fictional exercise, the target is correct completion of 99.5% of 200000 eligible operations within a defined window. The corresponding budget permits 1000 unsuccessful operations; it does not represent downtime minutes without another definition. Discuss what counts as success and how pending asynchronous operations are handled. For a significant decision, record context, alternatives, choice, consequences, and confidence in an ADR. When new evidence changes the choice, create a record superseding the earlier one while preserving historical rationale. In APS work, this helps explain why a queue, replica, or maintenance window exists and when the decision needs review.
200000×0.5%=1000 operations; budget units follow the indicator definition.
Common pitfalls
Technology before requirements; averages without population; SLO as automatic SLA; deleting old decisions.
Related topics: Capacity and latency · Data and consistency · Caching, partitions, and queues
Connect each choice to a requirement and supporting evidence.
Reference: Maintain an architecture decision record · System design patterns; PostgreSQL18 scoped examples; primary guidance consulted 2026-09-30