Requisitos

Dois engenheiros da BoxOffice recebem o mesmo pedido da equipe de produto: "Precisamos de uma plataforma de ingressos rápida, escalável e confiável." O primeiro começa a desenhar caixas. O segundo pergunta: Quantos eventos por mês? Quantos fãs no pico de uma abertura de vendas? O que significa "rápido" — para navegar ou para pagar? Podemos algum dia vender o mesmo lugar duas vezes? O que acontece se o provedor de pagamentos cair? Três meses depois, o primeiro engenheiro tem uma bela arquitetura para o problema errado. O segundo tem um diagrama menos impressionante, que sobrevive às 10:00 de sexta-feira.

Requisitos são a entrada de todo design. Um design só pode ser julgado em relação a eles: "esta é uma boa arquitetura?" é uma pergunta sem resposta; "esta arquitetura mantém o p99 do checkout abaixo de 1,5 s com 60.000 lugares e 2 milhões de fãs, sem venda duplicada, por menos de R$ 40 mil por mês?" é uma pergunta que você pode testar.

Dois tipos de requisito

Os requisitos funcionais decidem quais APIs e dados existem. Os não funcionais decidem qual arquitetura os entrega. Em design de sistemas, o lado não funcional comanda quase todas as decisões: a mesma funcionalidade "vender um ingresso" pode ser uma única tabela do PostgreSQL para um teatro de 200 lugares, ou uma sala de espera, um inventário particionado e um event stream para um estádio.

Requisitos funcionais

Comece pelos atores (quem usa o sistema) e seus objetivos. Para a BoxOffice:

Depois, transforme os objetivos numa lista curta e priorizada. Na prática — e numa entrevista — você não consegue projetar tudo, então escolhe o caminho principal e diz explicitamente o que fica fora do escopo:

Uma boa forma de verificar se um requisito funcional está completo é esboçar sua API. Se você não consegue escrever a requisição e a resposta, o requisito ainda está vago:

GET  /events?city=sao-paulo&from=2027-03-01&q=rock      → 200 [ {eventId, name, venue, date, minPrice} ]
GET  /events/{eventId}/seats                            → 200 { sections: [...], available: [...] }
POST /events/{eventId}/holds   { seatIds: [...] }       → 201 { holdId, expiresAt }   | 409 seat taken
POST /orders                   { holdId, paymentToken } → 201 { orderId, status }     | 402 declined
GET  /orders/{orderId}                                  → 200 { status, tickets: [...] }

Você vai detalhar APIs e modelos de dados na aula 5 e na aula 6; nesta etapa o objetivo é apenas tornar o escopo concreto.

Requisitos não funcionais: os atributos de qualidade

Requisitos não funcionais descrevem qualidades do sistema. A literatura de arquitetura de software os chama de atributos de qualidade¹ (a ISO/IEC 25010 padroniza uma longa lista deles²). Para design de sistemas, oito carregam a maior parte do peso:

O restante desta seção dá a cada atributo um significado preciso — "escalável" e "disponível" são usados de forma vaga no dia a dia, e palavras vagas geram requisitos ruins.

Escalabilidade

Escalabilidade é a capacidade de lidar com mais carga acrescentando recursos, mantendo um desempenho aceitável. Não é uma propriedade sim/não: "é escalável?" não tem sentido até você dizer qual parâmetro de carga cresce e quanto³. Na BoxOffice, os parâmetros de carga diferem de uma parte do sistema para outra:

• catalog: visualizações de página por segundo (dominado por leituras, altamente cacheável);
• inventory: reservas de lugares por segundo num único evento (dominado por escritas, todas nas mesmas linhas quentes);
• notification: e-mails por minuto depois de uma abertura de vendas (em rajadas, podem atrasar).

Cada um escala com uma técnica diferente: cache e CDN para o primeiro, particionamento e sala de espera para o segundo, fila e workers para o terceiro. Existem duas direções, e você usará as duas:

• Escala vertical (scale up): uma máquina maior. Simples, sem mudar o código, mas limitada pela maior máquina que você consegue comprar, e ainda um ponto único de falha.
• Escala horizontal (scale out): mais máquinas. Praticamente ilimitada para componentes sem estado, mas exige um load balancer, servidores sem estado e — para os dados — particionamento e replicação.

Disponibilidade

Disponibilidade é a fração do tempo (ou das requisições) em que o sistema atende os usuários corretamente. Ela é expressa em "noves" e sempre numa janela: 99,9% em janela móvel de 28 dias permite cerca de 40 minutos de indisponibilidade; 99,99% permite cerca de 4 minutos. Cada nove a mais custa muito mais que o anterior — a aula 2 dá a matemática, e a aula 10, a engenharia.

A disponibilidade também não é uniforme: a BoxOffice convive com o widget de recomendações fora do ar por uma hora, mas não com o checkout fora do ar durante uma abertura de vendas.

Latência (e throughput)

Latência (tempo de resposta) é quanto tempo uma requisição leva, vista pelo cliente. Throughput é quantas requisições por segundo o sistema conclui. Os dois estão ligados — perto da saturação, a latência explode (aula 2) —, então uma meta de latência só faz sentido para um dado throughput.

Sempre expresse a latência como um percentil, não como uma média: "p99 < 300 ms" significa que 99% das requisições terminam em menos de 300 ms. Médias escondem as requisições lentas de que os usuários se lembram (percentis e latência de cauda). Pesquisas clássicas de usabilidade dão âncoras úteis para metas voltadas ao usuário: cerca de 0,1 s parece instantâneo, cerca de 1 s mantém o fluxo de pensamento do usuário e, além de cerca de 10 s, os usuários perdem a atenção⁴.

Consistência

Consistência (no sentido de design de sistemas) diz respeito ao que os leitores veem depois de uma escrita. Com consistência forte, uma vez que uma escrita é confirmada, toda leitura seguinte a enxerga — o sistema se comporta como se houvesse uma única cópia do dado. Com consistência eventual, as réplicas podem discordar por um tempo, mas convergem se as escritas pararem.

A ideia-chave é que nem todo dado precisa da mesma consistência:

Consistência forte custa latência e disponibilidade (você verá por quê com CAP e PACELC na aula 3), então você paga por ela só onde o negócio precisa.

Durabilidade

Durabilidade significa que um dado, uma vez confirmado, não se perde — mesmo se discos, máquinas ou um data centre inteiro falharem. Ela é obtida com replicação (várias cópias, de preferência em domínios de falha diferentes), logs de escrita antecipada (write-ahead logs), backups e restaurações testadas. O requisito normalmente é expresso como um RPO (Recovery Point Objective — quanto dado recente você pode perder num desastre): para os pedidos da BoxOffice, RPO = 0; para eventos de analytics, alguns minutos são aceitáveis.

Não confunda durabilidade com disponibilidade: um banco pode estar fora do ar (indisponível) sem perder nada (durável) e, ao contrário, um cache pode estar no ar sem guardar nada de forma durável.

Custo

Todo componente tem um preço: máquinas, serviços gerenciados, armazenamento, tráfego de saída da rede, taxas de terceiros e as pessoas para operá-lo. Custo é um requisito de primeira classe — uma arquitetura que cumpre todas as outras metas a dez vezes o orçamento é uma arquitetura fracassada. Bons requisitos de custo são ligados ao negócio: custo por ingresso vendido, custo por usuário ativo ou um teto mensal. Repare também que o tráfego da BoxOffice é em picos: pagar o mês inteiro pela capacidade de uma abertura de vendas de 10 minutos é desperdício, e é por isso que autoscaling, filas e serverless importam (a aula 11 trata de FinOps).

Segurança

Segurança protege a confidencialidade (só as pessoas certas leem os dados), a integridade (só as pessoas certas os alteram) e a disponibilidade (atacantes não conseguem derrubá-los) — a tríade CIA. Na BoxOffice, ela se traduz em requisitos concretos: fãs se autenticam antes de comprar; um organizador só vê os próprios eventos; robôs não conseguem comprar 500 ingressos em um segundo; números de cartão nunca passam pelos servidores da BoxOffice (o provedor de pagamentos os tokeniza, o que deixa a BoxOffice fora da maior parte do escopo do PCI DSS⁵); dados pessoais seguem a lei brasileira de proteção de dados, a LGPD (Lei Geral de Proteção de Dados)⁶.

Operabilidade

Operabilidade reúne as qualidades que tornam um sistema operável por pessoas reais: observabilidade (conseguimos dizer o que está errado?), facilidade de deploy (conseguimos publicar uma mudança com segurança, várias vezes por dia?), manutenibilidade (um engenheiro novo consegue entendê-lo e alterá-lo?) e recuperabilidade (com que rapidez restauramos o serviço — o MTTR, Mean Time To Recovery). É o atributo mais esquecido nos diagramas e mais culpado nos post-mortems.

Tornando os requisitos não funcionais mensuráveis

"O sistema deve ser rápido" não pode ser testado, então não pode ser projetado. Um modelo prático da arquitetura de software é o cenário de atributo de qualidade¹, que força seis partes numa só frase:

flowchart LR
    source["Fonte<br/>quem/o quê"] --> stimulus["Estímulo<br/>o que acontece"]
    stimulus --> artifact["Artefato<br/>qual parte, em qual<br/>ambiente"]
    artifact --> response["Resposta<br/>o que o sistema faz"]
    response --> measure["Medida da resposta<br/>o número"]

Escrito como requisitos, um conjunto mensurável para a BoxOffice fica assim:

Cada linha é testável — com um teste de carga, um experimento de caos ou a fatura do mês — e cada linha vai guiar uma decisão de design nas próximas aulas.

export const options = {
  vus: 1,
  duration: '30s',
  summaryTrendStats: ['avg', 'med', 'p(95)', 'p(99)', 'max'],
  thresholds: {
    http_req_failed: ['rate==0'],
    // one threshold per endpoint makes k6 print one latency line per endpoint
    'http_req_duration{name:GET /catalog/events/{id}}': ['p(95)<200'],
    'http_req_duration{name:GET /catalog/events?city}': ['p(95)<500'],
  },
};

Trade-offs entre atributos de qualidade

Os atributos de qualidade puxam uns contra os outros. Reconhecer a tensão antes de escolher um componente é a essência do design de sistemas:

É por isso que a mesma empresa roda arquiteturas diferentes para partes diferentes do mesmo produto. O catálogo da BoxOffice é um sistema inclinado a AP, com cache em tudo; seu inventário é um sistema inclinado a CP, com transação em tudo; suas notificações são um sistema assíncrono, que tenta de novo até entregar.

Restrições e premissas

Os requisitos vêm acompanhados de restrições — decisões já tomadas por você — e de premissas — coisas que você assume como verdadeiras para seguir em frente:

• Equipe e competências: uma equipe de seis pessoas que conhece Java e PostgreSQL não deveria adotar cinco bancos de dados novos.
• Prazo: "abertura de vendas em 8 semanas" descarta reescrever tudo como microsserviços.
• Orçamento: um teto mensal, ou uma meta de custo por ingresso.
• Regulação: LGPD para dados pessoais; PCI DSS para pagamentos; regras fiscais para notas.
• Sistemas existentes: a API do provedor de pagamentos e seus limites de taxa; o ERP do organizador.
• Premissas: "os fãs por abertura de vendas seguem a distribuição do ano passado", "o provedor responde em 300–800 ms". Anote-as — quando uma premissa estiver errada, você saberá qual parte do design rever.

Como se conecta

flowchart LR
    FR["requisitos funcionais<br/>atores, caminho principal"] --> API["API e modelo de dados<br/>→ Compute, Bancos de dados"]
    NFR["atributos de qualidade"] --> QAS["cenário de atributo de qualidade<br/>uma meta mensurável"]
    QAS --> EST["números de carga<br/>→ Estimativa"]
    NFR --> SC["escalabilidade<br/>lb, cache, queue"]
    NFR --> LAT["percentis de latência<br/>→ Estimativa"]
    NFR --> AV["noves de disponibilidade<br/>→ Confiabilidade"]
    NFR --> CO["consistência por dado<br/>→ Sistemas distribuídos"]
    NFR --> SEC["segurança<br/>→ Rede e Segurança"]
    NFR --> OPS["operabilidade<br/>→ Observabilidade"]
    CO --> TO["trade-offs: inventário CP,<br/>catálogo AP"]
    LAT --> TO

Componentes da paleta: client · mobile (os pontos de entrada dos atores) · sql (consistência forte para assentos, durabilidade dos pedidos) · cache · cdn (latência comprada com frescor) · lb (escalabilidade e disponibilidade por meio de réplicas) · waf · auth (segurança) · payment (uma restrição externa: nenhum dado de cartão armazenado) · metrics (operabilidade). Cenários: monolith, flash-sale. Continua em: Estimativa — números, Estimativa — percentis, Estimativa — matemática da disponibilidade, Distribuídos — CAP e PACELC, Observabilidade — SLOs, Exercício: design doc.

Pontos-chave