Aula 02 · 80–100 minutos

Requisitos, qualidade e restrições: pare de projetar contra frases vagas

Aula de System Design sobre requisitos funcionais, atributos de qualidade e restrições.

Resultado e conexão com a aula anterior

Na aula 01, você partiu de uma necessidade e desenhou um caminho crítico. Agora você vai tornar a necessidade precisa antes de defender qualquer caixa. Ao final, você poderá classificar uma afirmação, descobrir a pergunta que falta, escrever a versão verificável e explicar qual decisão de arquitetura ela realmente pressiona.

  1. Separar comportamento, qualidade e limite externo.
  2. Converter adjetivos em uma medida com população, alvo e janela.
  3. Trazer segurança e idempotência para o contrato, não para o rodapé.
  4. Produzir uma tabela requisito → decisão → evidência e um ADR curto.

O mesmo pedido contém três coisas diferentes

Considere: "o cliente precisa retirar o pedido na loja; a confirmação deve ser imediata; os dados precisam ficar no Brasil; o parceiro de pagamento aceita no máximo 50 rps". Não é uma lista homogênea. Misturá-la leva a respostas como "vamos usar microserviços" antes de saber o que o sistema deve fazer, quanto precisa entregar ou o que não pode mudar.

Essas categorias são uma ferramenta de raciocínio, não uma lei universal. Algumas frases pertencem a mais de uma: "somente o dono pode cancelar o pedido" é comportamento necessário e uma condição de segurança verificável.

Fluxo: da frase à evidência

Use os controles do diagrama para comparar as composições e seguir as relações.

Use o ramo inferior quando ouvir um adjetivo sem medida. "Rápido" não alimenta uma decisão; a pergunta "qual operação, para qual população e qual limite?" sim. O fluxo termina em evidência porque um requisito sem teste, métrica ou observação ainda é uma hipótese.

Leitura do fluxo: primeiro classifique a frase; em seguida, torne-a mensurável ou registre o limite externo; só então escolha componentes. O teste de carga, o teste de autorização, a métrica de latência ou uma revisão de residência de dados verifica a promessa depois.

Como escrever cada categoria sem ambiguidade

1. Funcional: ator, ação, recurso, sucesso e falha

Em vez de "gerenciar pedidos", escreva: "um cliente autenticado cria um pedido de retirada e recebe um identificador; se a loja não puder aceitar, recebe um estado explícito". Isso revela estados, ownership e casos de erro. A orientação de resiliência da AWS recomenda documentar requisitos funcionais e histórias de usuário antes do desenho.

2. Qualidade: jornada, população, medida, alvo, janela

"Imediato" vira: "para requisições válidas de CreateOrder, p95 de latência ≤ 800 ms em janela móvel de 28 dias". O Google SRE Book define SLI como medida quantitativa e SLO como seu alvo; comece pelo que a pessoa usuária valoriza, não pelo que é mais fácil medir. Pergunte também: o que fazemos quando o alvo falha?

3. Restrição: fato, origem, duração e margem

"50 rps do parceiro" não é preferência. Registre fonte, escopo, timeout, data de revisão e o comportamento acima do teto. Uma fila pode absorver uma rajada, mas não torna uma taxa sustentada maior que o consumo magicamente segura: defina limite, backpressure e degradação. "Usar Kafka" é uma solução candidata, não uma restrição.

Segurança e retries mudam o contrato

Um endpoint que recebe orderId não ganhou autorização por existir autenticação. A OWASP API1:2023 exige verificação de autorização em cada operação que age sobre um objeto. Portanto: "somente o criador ou atendente da mesma loja vê/cancela o pedido" precisa de uma decisão server-side, testes negativos e um sinal de tentativas negadas — nunca confiança no identificador fornecido pelo cliente.

Também declare repetição. A RFC 9110 §9.2.2 define idempotência como o mesmo efeito pretendido para múltiplas requisições idênticas. Criar/cobrar pede uma chave de idempotência, fronteira de deduplicação e definição explícita de efeitos que não podem duplicar.

Decisões nascem da pressão do requisito

O requisito não escolhe a tecnologia, mas elimina soluções incapazes de cumprir a promessa. Uma escolha é defendível quando aponta para a frase que a tornou necessária e para a evidência que poderá revê-la.

Alternativas insuficientes

"O sistema deve escalar." Escalar qual jornada, de qual pico, até quando e qual recurso é o gargalo? Sem isso, não existe critério para cache, fila ou particionamento.

"Alta disponibilidade para tudo." A meta precisa de escopo e custo. A leitura de catálogo pode degradar de forma diferente de criar pedido; prometer a mesma disponibilidade a tudo esconde prioridades.

"Vamos processar pagamento assíncrono." Falta estado devolvido, UX, idempotência, limite de fila, timeout e recuperação. Assíncrono descreve mecânica, não promessa.

"O frontend verifica se é dono." Controle de interface não é autorização. Um cliente pode chamar a API com outro ID; a verificação precisa estar no servidor que arbitra o recurso.

Prática guiada: retirada em loja

Recupere da memória: 10 questões

Recupere da memória: 10 questões

“Criar pedido” é principalmente:

Qual torna “rápido” verificável?

“Parceiro aceita 50 rps” é:

Quem arbitra acesso a pedido?

Chave de idempotência protege:

Notificação em cinco minutos pressiona:

“Usar microserviços” é normalmente:

Evidência de autorização é:

Fila ilimitada sob sobrecarga:

Um ADR liga decisão a:

Perguntas de entrevista e revisão

"Como diferencia requisito funcional de não funcional?" "Funcional descreve comportamento. Qualidade descreve como uma jornada se comporta e só orienta design com população, medida, alvo e janela. Restrição limita alternativas antes da escolha."

"Por que não escolher logo fila para pagamento?" "Primeiro valido se o produto aceita estado intermediário. Depois declaro quota, timeout, idempotência, limite de fila, UX e recuperação. A fila responde a uma pressão; não substitui contrato."

"Como segurança entra?" "Como comportamento e condição de aceitação: defino quem pode agir sobre cada objeto, verifico no servidor e testo acesso cruzado. Autenticação não prova autorização."

Próximo passo e referências

Escolha um adjetivo vago de uma conversa real, formule a pergunta que falta e escreva sua versão verificável. Traga-a ao agente para crítica. Na próxima aula, limites viram estimativas de tráfego, armazenamento e custo.

Leitura primária recomendada: Google SRE Book — Service Level Objectives. Consulte também AWS — Understanding the workload, RFC 9110 §9.2 e AWS — ADR process.

Pesquisa: registro de fontes da aula · Diagrama: da frase vaga ao requisito verificável.