Conceito e mecanismo
Conceber um sistema começa por compreender quem o utiliza, que resultados precisa de obter e o que acontece quando falha. Uma lista de tecnologias não responde a essas perguntas. Identifica operações críticas, frequência, volume, prazo, dados e dependências externas. Separa restrições obrigatórias de preferências e hipóteses ainda por confirmar. Um requisito como rápido precisa de população, métrica, limiar e janela de observação. O SLI mede um aspeto do serviço; o SLO define o objetivo para essa medida. Um SLA tem âmbito contratual próprio e não deve ser deduzido automaticamente do objetivo interno. O desenho precisa de tornar visível o resultado percebido pelo utilizador.
Aplicação guiada
Num exercício fictício, o objetivo é concluir corretamente 99,5% de 200000 operações elegíveis numa janela definida. O orçamento correspondente admite 1000 operações sem sucesso; não representa minutos de indisponibilidade sem outra definição. Discute o que conta como sucesso e como tratar operações assíncronas pendentes. Para uma decisão importante, regista contexto, alternativas, escolha, consequências e confiança num ADR. Quando nova evidência altera a escolha, cria um registo que substitui o anterior, preservando a razão histórica. No trabalho de APS, isto ajuda a explicar por que existe uma fila, uma réplica ou uma janela de manutenção e quando a decisão deve ser revista.
200000×0,5%=1000 operações; a unidade do orçamento segue a definição do indicador.
Armadilhas comuns
Tecnologia antes do requisito; média sem população; SLO como SLA automático; apagar decisões antigas.
Tópicos relacionados: Capacidade e latência · Dados e consistência · Cache, partições e filas
Liga cada escolha a um requisito e à evidência que a suporta.
Referência: Maintain an architecture decision record · System design patterns; PostgreSQL18 scoped examples; primary guidance consulted 2026-09-30