Visão geral

Sexta-feira, 10:00. A BoxOffice, uma pequena start-up de ingressos, abre a venda do maior show de estádio do ano: 60.000 lugares, 2 milhões de fãs atualizando a página no mesmo segundo. Às 10:00:04 o site responde em 9 segundos. Às 10:00:20 não responde mais nada. Às 10:03 ele volta — e 312 lugares foram vendidos duas vezes. O código não tinha nenhum bug que um teste unitário pudesse pegar: cada função fez exatamente o que foi escrita para fazer. O que falhou foi o sistema: quantas máquinas, qual banco de dados, onde os dados ficam, o que espera pelo quê e o que acontece quando 2 milhões de pessoas chegam ao mesmo tempo.

Esta disciplina trata dessa camada — as decisões que ficam acima do código e decidem se o código sobrevive ao contato com a realidade. Ao final do semestre você será capaz de projetar a BoxOffice para que as 10:00 de sexta-feira sejam um não-evento, medir que funciona e defender cada decisão com números, numa revisão de design ou numa entrevista de system design.

Roteiro

1. Esta visão geral — o que é design de sistemas, a paleta de componentes que organiza a disciplina e como usar o playground.
2. Requisitos — requisitos funcionais e não funcionais; os atributos de qualidade e como torná-los mensuráveis.
3. A Jornada de Escala — a BoxOffice de 1 usuário a 10 milhões: primeiro o monólito, depois um componente por sintoma.
4. O Método da Entrevista — um método de 7 passos e 45 minutos para problemas de design abertos.
5. Quiz — verifique seu entendimento.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

O que é design de sistemas?

Design de sistemas (system design) é o processo de definir os componentes de um sistema, as interfaces entre eles e os dados que passam por eles e são armazenados por eles, de modo que o sistema satisfaça seus requisitos — tanto o que ele deve fazer quanto quão bem deve fazê-lo¹. Ele responde a perguntas como:

• De quantos servidores precisamos, e o que acontece quando um deles morre?
• Onde fica cada dado, quem pode alterá-lo e com que rapidez cada leitor precisa ver a alteração?
• Que trabalho precisa acontecer agora, enquanto o usuário espera, e qual pode acontecer depois?
• Quanto isso custa por mês, e o que quebra primeiro se o tráfego dobrar?

Vale a pena colocar o design de sistemas ao lado do trabalho de design que você já conhece:

O salto do design de software para o design de sistemas é um salto de um processo para muitos processos em muitas máquinas, ligados por uma rede não confiável. Esse salto traz três realidades novas:

1. Carga — o sistema precisa continuar funcionando quando muitos usuários chegam ao mesmo tempo. Dez usuários e dez milhões de usuários pedem arquiteturas diferentes, não apenas mais do mesmo.
2. Falha parcial — algumas partes falham enquanto outras continuam rodando. Um disco enche, um nó reinicia, uma API de terceiros fica lenta. O sistema precisa cumprir suas promessas mesmo assim.
3. Trade-offs — quase toda decisão compra uma qualidade com outra. Um cache compra latência com frescor dos dados; uma réplica compra disponibilidade com consistência; uma fila compra resiliência com imediatismo.

Por que isso importa para você

• No trabalho, quase toda funcionalidade acaba levantando uma questão de sistema: Esta consulta vai ser rápida com 50 milhões de linhas? Este e-mail deve ser enviado de forma síncrona? O que acontece se o provedor de pagamentos cair? Engenheiros que respondem com números tomam decisões melhores e recebem decisões maiores.
• Em entrevistas, system design é uma etapa padrão para vagas de engenharia de software na maioria das empresas de tecnologia. Ela é aberta de propósito: o entrevistador observa como você pensa — como esclarece, estima, estrutura e lida com trade-offs².
• Nesta disciplina, é o fio que liga tudo, do DNS aos agentes de IA: cada tópico é um componente que você acrescenta a um design por um motivo que pode medir.

BoxOffice, o exemplo da disciplina

Cada aula, laboratório, quiz e conjunto de slides usa o mesmo sistema fictício, para que cada conceito novo caia sobre um problema que você já conhece. A BoxOffice vende ingressos para shows, jogos e festivais. Ela foi escolhida porque tem, de propósito, todas as propriedades difíceis que um sistema real pode ter — e elas são intuitivas:

Seus serviços — que você vai construir, medir e quebrar nos laboratórios — são gateway, auth, catalog (eventos e locais), inventory (lugares e reservas), order, payment (adaptador para um provedor externo), notification, search e assistant (IA). O código fica no repositório da disciplina, https://github.com/repo-classes/pma271.

É para cá que a BoxOffice caminha até o fim do semestre. Aperte play para acompanhar uma compra através dela:

flowchart LR
    fan([Fã]) --> cdn["CDN"]
    fan --> waf["WAF"]
    waf --> gw["API Gateway"]
    gw --> auth["auth"]
    gw --> catalog["catalog"]
    catalog --> cache[("Cache")]
    cache --> catdb[("SQL")]
    gw --> wr["Sala de espera<br/>(fila)"]
    wr --> inventory["inventory"]
    inventory --> invdb[("SQL<br/>lugares e reservas")]
    inventory --> order["order"]
    order --> payment["payment"]
    payment --> psp["Provedor de pagamento<br/>(externo)"]
    order --> kafka["Event stream"]
    kafka --> notification["notification"]
    notification --> email["E-mail / push"]

Você não precisa entender cada caixa hoje. O objetivo da disciplina é que, na semana 15, você consiga explicar por que cada caixa está ali, que número faria você removê-la e o que acrescentaria em seguida.

A paleta de componentes

Arquiteturas reais são montadas a partir de um conjunto surpreendentemente pequeno de blocos. A disciplina é organizada em torno de uma paleta de componentes — a mesma paleta que o simulador da disciplina usa. Cada aula teórica ensina um grupo de componentes: o que cada um faz, quando usá-lo, quando não usá-lo, os números que o descrevem e como ele falha.

As demais aulas são transversais: não acrescentam caixas, mas dão as ferramentas para raciocinar sobre todas elas.

flowchart TB
    subgraph F["Fundamentos"]
        direction LR
        c1["1. Introdução e<br/>método da entrevista"] --> c2["2. Estimativas e<br/>matemática de desempenho"] --> c3["3. Sistemas<br/>distribuídos"]
    end
    subgraph P["A paleta, um grupo por aula"]
        direction LR
        c4["4. Borda"] --> c5["5. Computação"] --> c6["6. Bancos de dados"] --> c7["7. Cache"] --> c8["8. Mensageria"]
    end
    subgraph O["Rodando em produção"]
        direction LR
        c9["9. Confiabilidade"] --> c10["10. Observabilidade"] --> c11["11. Rede e<br/>segurança"] --> c12["12. Cloud-native"]
    end
    subgraph X["Juntando tudo"]
        direction LR
        c13["13. Sistemas de IA"] --> c14["14. Entrega assistida<br/>por IA"] --> c15["15. Desempenho e<br/>testes de carga"] --> c16["16. Estudos de caso"]
    end
    F --> P --> O --> X

Cada componente tem uma entrada no catálogo de componentes — por exemplo Load Balancer, Cache ou Message Queue — com uma definição de uma linha para entrevistas, números-chave, modos de falha e os produtos reais (AWS, GCP, Azure, open source) que o implementam. Use-o como dicionário durante a leitura.

O System Design Playground

Ler sobre um cache não é o mesmo que ver a latência p99 cair quando a taxa de acerto sobe. A disciplina vem com um simulador, o System Design Playground, em que cada componente da paleta é um bloco que você solta numa tela, conecta e coloca sob carga. Ele é um modelo — não executa código real —, mas reproduz o comportamento que importa para o design: filas que crescem quando um componente está saturado, latência que explode perto da utilização máxima, falhas que se propagam em cascata quando não há timeouts, custo que cresce a cada réplica.

O fluxo de trabalho é sempre o mesmo:

1. Montar — escolha componentes da paleta e conecte-os (cliente → load balancer → app → banco de dados…).
2. Configurar — defina capacidades, réplicas, taxas de acerto de cache, timeouts.
3. Carregar — escolha um perfil de carga: smoke (um fio de tráfego, para verificar que funciona), load (o tráfego esperado), stress (além dele), spike (um salto repentino, como as 10:00 de sexta), soak (horas a uma taxa constante), breakpoint (rampa até algo quebrar), chaos (injeção de falhas).
4. Ler — acompanhe throughput, percentis de latência (p50, p99), taxa de erros, utilização por componente e custo mensal.
5. Mudar uma coisa e rodar de novo. É o método científico aplicado à arquitetura, e é exatamente o que você fará com sistemas reais nos laboratórios.

Ao longo da disciplina, as páginas incorporam o playground já carregado com um cenário. Aqui está o primeiro: a BoxOffice como um único servidor de aplicação e um único banco SQL.

Experimente: comece com o perfil load e anote a latência p99 e a utilização da aplicação e do banco. Depois mude para spike. Qual componente satura primeiro? O que acontece com a latência antes de os erros aparecerem? Anote a taxa de requisições em que as coisas deram errado — você vai calculá-la à mão na aula 2.

O segundo cenário coloca um load balancer na frente de várias réplicas da aplicação.

Experimente: rode o perfil stress com 1 réplica, depois 2, depois 4. O throughput dobra a cada vez? Observe o banco de dados: a partir de certo ponto, acrescentar réplicas da aplicação deixa de ajudar. Por quê? Depois derrube uma réplica (ou use o perfil chaos) e veja o que os health checks fazem.

O mapa de conceitos da introdução

Esta aula passa de leve por toda a paleta: cada atributo de qualidade (azul) é comprado com alguns componentes da paleta (verde), e a jornada de escala os adiciona um sintoma medido de cada vez. Use o mapa como índice para o resto do curso:

flowchart LR
    client["client · mobile"]:::comp --> req["requisitos:<br/>funcionais + atributos de qualidade"]:::tech
    req --> scal["escalabilidade"]:::tech
    req --> lat["latência"]:::tech
    req --> avail["disponibilidade"]:::tech
    req --> cons["consistência,<br/>durabilidade"]:::tech
    req --> sec["segurança"]:::tech
    req --> ops["operabilidade"]:::tech
    scal --> c1["lb · réplicas de app ·<br/>queue · worker · nosql"]:::comp
    lat --> c2["cache · cdn"]:::comp
    avail --> c3["healthcheck · failover de dns"]:::comp
    cons --> c4["sql · objstore"]:::comp
    sec --> c5["waf · apigw · auth"]:::comp
    ops --> c6["metrics · logs · tracing"]:::comp
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Como estudar design de sistemas

• Desenhe. Todo conceito desta disciplina tem uma figura. Se você não consegue desenhá-lo, ainda não o entendeu.
• Estime antes de projetar. Um design para 100 requisições por segundo e outro para 100.000 são designs diferentes. A aula 2 dá os números e as fórmulas.
• Dê nome ao trade-off. Para cada componente que você acrescenta, diga o que ele compra e quanto custa: "o cache reduz o p99 do catálogo de 80 ms para 5 ms, ao preço de mostrar um preço com até 60 s de atraso".
• Quebre coisas de propósito. No playground e nos laboratórios, encontre o ponto de ruptura e depois corrija-o. Você aprende mais com uma saturação do que com dez diagramas.
• Pratique em voz alta. Design de sistemas é uma conversa. Use o método da entrevista com um colega toda semana, a partir de agora.

Relacionados

• Laboratórios: 0. Ambiente (ferramentas e o repositório da disciplina) e 1. Primeiro serviço (a API catalog).
• Exercício: Design no playground — resolver desafios do playground com metas de SLO e custo.
• Estudo de caso: Venda de ingressos — a venda relâmpago da BoxOffice, o design completo do sistema apresentado aqui.
• Entrevista: Método da entrevista e problemas para praticar.

Pontos-chave

O que quebra em seguida

Os requisitos agora têm números — 2 milhões de fãs no primeiro minuto, 60.000 lugares, p99 da reserva < 300 ms, checkout disponível 99,95% do tempo —, mas ninguém os conferiu contra o único PostgreSQL em que a BoxOffice roda. Se ele aguenta a abertura das 10:00 não é questão de opinião, é aritmética: requisições por segundo, o tempo que uma reserva ocupa o banco, quão cheio ele pode rodar antes de a latência explodir. Fazer essa conta, e encontrar ~33.000 tentativas de reserva/s contra ~1.100 que um banco sustenta, é a aula 2 — Estimativas.