Arquitetura de Sistemas — 2027.1

A maioria dos sistemas que você vai construir ou manter na carreira precisa ser rápida, disponível, consistente o suficiente, segura e barata — ao mesmo tempo, sob carga, enquanto partes dela falham. Esta edição da disciplina trata de como projetar esses sistemas, como provar com números que um design funciona e como explicá-lo — para um time numa revisão de design e para um entrevistador numa entrevista de system design.

O exemplo condutor: BoxOffice

Um show no estádio abre as vendas às 10:00. Dois milhões de fãs, sessenta mil lugares. O catálogo é dominado por leituras, o estoque de lugares nunca pode vender o mesmo lugar duas vezes, os pagamentos passam por um provedor externo que às vezes fica lento, as confirmações saem por e-mail, bots tentam comprar tudo e um assistente de IA responde "encontre dois lugares abaixo de R$ 300 para sábado e reserve". Quase todo tema da disciplina aparece neste único sistema.

flowchart LR
    U["fãs<br/>(web, mobile)"] --> DNS["DNS"] --> CDN["CDN"] --> WAF["WAF"] --> GW["API gateway"]
    GW --> AUTH["auth"]
    GW --> CAT["catalog"] --> CACHE[("cache")]
    CACHE --> SQL[("SQL")]
    GW --> Q["sala de espera<br/>(fila)"] --> INV["inventory<br/>(reservas de lugar)"] --> SQL
    INV --> ORD["order"] --> PAY["payment"] --> EXT["provedor de pagamento"]
    ORD --> K["stream de eventos"] --> NOTIF["notification"] --> MAIL["e-mail"]
    K --> AN["analytics / DWH"]
    GW --> AI["assistente<br/>(gateway de LLM, ferramentas, RAG)"]

A história da disciplina

As aulas não são uma lista de temas: são os capítulos de uma única história. O BoxOffice começa como um serviço e um banco de dados, e cada capítulo começa com o problema que o anterior deixou, expresso com um número. Um componente só entra no design quando um número o exige, e cada um traz um novo problema. Aperte play para seguir a cadeia:

flowchart TD
    C1["1. O que o BoxOffice precisa fazer, e quão bem?"] -->|"2 M de fãs, 60 mil lugares, p99 < 300 ms:<br/>um banco de dados basta?"| C2["2. Estime antes de construir"]
    C2 -->|"33.000 holds/s contra ~1.100:<br/>precisamos de mais de uma máquina"| C3["3. Mais máquinas, uma rede que mente"]
    C3 -->|"as réplicas existem: quem recebe<br/>as 2 M de requisições às 10:00?"| C4["4. Tráfego, borda e identidade"]
    C4 -->|"a borda espalha a carga entre réplicas:<br/>o que uma réplica precisa ser?"| C5["5. Computação e serviços"]
    C5 -->|"serviços stateless empurram todo<br/>o estado para o banco"| C6["6. Bancos de dados"]
    C6 -->|"as páginas de evento são lidas 100× mais<br/>do que mudam"| C7["7. Cache"]
    C7 -->|"o checkout ainda espera<br/>pelo provedor de e-mail"| C8["8. Mensageria"]
    C8 -->|"a assincronia esconde falhas:<br/>para onde foi aquele pedido?"| C9["9. Observabilidade"]
    C9 -->|"agora enxergamos: o provedor responde<br/>em 4 s e arrasta o checkout junto"| C10["10. Confiabilidade"]
    C10 -->|"um notebook com Compose não se cura,<br/>não escala nem faz deploy com segurança"| C11["11. Plataformas cloud-native"]
    C11 -->|"muitos serviços numa plataforma:<br/>quem pode falar com quem? o que entregamos?"| C12["12. Redes e segurança"]
    C12 -->|"os fãs perguntam em linguagem natural:<br/>'dois lugares abaixo de R$ 300, sábado'"| C13["13. Sistemas de IA"]
    C13 -->|"mais mudanças, mais rápido:<br/>quem revisa, testa, faz o release?"| C14["14. Entrega assistida por IA"]
    C14 -->|"o design inteiro aguenta<br/>a próxima abertura de vendas? prove"| C15["15. Engenharia de desempenho"]
    C15 -->|"os mesmos blocos, outros sistemas"| C16["16. Estudos de caso"]

Cada linha da tabela é um capítulo: o problema que o abre, a aula que o responde, o lab em que você constrói a resposta no BoxOffice (e o arquivo para ler primeiro) e o cenário do playground em que você o vê falhar e se recuperar. O planejamento põe os capítulos no calendário.

Mapa da disciplina

O plano semana a semana está na página de planejamento.

Encontros

Professores

Nota

1. Exercícios (individuais): sete exercícios — estimativas, relatório de teste de carga, cache e banco de dados, orientado a eventos, autoscaling no Kubernetes, design no playground e documento de design — cada um avaliado com um conceito (A–I) e uma rubrica. Pesos e regras estão na página de exercícios.

2. Quizzes: três quizzes; o menor é descartado e a nota é a média dos dois melhores:

   \[ \text{Quizzes} = \frac{\text{Q}_1 + \text{Q}_2 + \text{Q}_3 - \min(\text{Q}_1, \text{Q}_2, \text{Q}_3)}{2} \]

3. Provas: uma prova intermediária e uma prova final, individuais, cobrindo as aulas e os labs. Parte de cada prova é uma questão curta de system design no formato do método da entrevista.

4. Projeto em equipe: equipes de 2 ou 3 estudantes constroem, medem, quebram de propósito e defendem um sistema, em nove marcos (documento de design, caminho principal, escala e cache, assíncrono e resiliência, Kubernetes + CI/CD, campanha de testes de carga, game day de caos, relatório de custos, apresentação). A nota da equipe é a mesma para todos os membros. Detalhes na página do projeto.

   Inscrição das equipes

   Prazo: fim da semana 3 (data na página de planejamento).

   Equipes de 2 a 3 membros, um repositório GitHub por equipe, documentação no GitHub Pages.

Repositórios

Repositório da disciplina (código dos labs e projetos iniciais): repo-classes/pma271 (a ser publicado).