Visão geral

São 09:59 do dia em que a turnê de estádios entra à venda na BoxOffice. Dois milhões de fãs estão atualizando a página do evento; existem 60 mil lugares. Nos próximos dez minutos a plataforma precisa renderizar o catálogo para milhões de visualizações de página, reservar e vender lugares sem venda duplicada, cobrar cartões por meio de um provedor de pagamentos externo, gerar 60 mil ingressos e e-mails e liberar os lugares cujas reservas expiraram. Às 03:00, a mesma plataforma atende algumas centenas de requisições por segundo.

A borda (aula 4) decide para onde vai cada requisição. Esta aula trata do que acontece quando ela chega: onde o código roda, como ele é dividido em serviços, como esses serviços conversam, o que roda fora da requisição, como a frota cresce e encolhe sozinha e como depender com segurança de sistemas que você não controla — o provedor de pagamentos, o provedor de e-mail, qualquer API de terceiros.

Roteiro

1. Esta visão geral — a paleta de computação, servidores de aplicação stateless, escalabilidade horizontal e quantas réplicas você precisa.
2. Serviços — monólito, monólito modular e microsserviços; bounded contexts de DDD; lei de Conway; a arquitetura dentro de um serviço; auth, busca, notificações e analytics como serviços.
3. Estilos de API — REST, gRPC, GraphQL e APIs assíncronas para o mesmo recurso da BoxOffice; contratos, OpenAPI e versionamento.
4. Trabalho assíncrono — workers e jobs em segundo plano, design de jobs, schedulers, locks distribuídos e eleição de líder.
5. Serverless e autoscaling — functions as a service, cold starts e concorrência; políticas de autoscaling, HPA e por que o escalonamento reativo fica atrás de uma venda relâmpago.
6. Integrações externas — APIs de terceiros, provedores de pagamento e de e-mail: webhooks com assinaturas, idempotency keys, retries, reconciliação e quedas do provedor.
7. 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

A paleta de computação

No System Design Playground, a categoria COMPUTE agrupa todos os componentes que executam o seu código. Cada um é uma resposta diferente à pergunta "onde esta parte da lógica executa, e como ela escala?":

O restante desta página trata do mais comum deles — o app server — e da propriedade que torna todo o resto possível: ser stateless.

App servers stateless

Um servidor é stateless (sem estado) quando não guarda, entre uma requisição e outra, nada de que outra réplica precisaria: qualquer réplica pode atender qualquer requisição, porque tudo o que precisa sobreviver fica fora do processo — em um banco de dados, um cache, um object store ou no próprio cliente. É essa única propriedade que permite ao load balancer mandar cada requisição para qualquer lugar, permite adicionar réplicas em segundos e permite matar uma réplica sem perder nada.

flowchart LR
    fan([Fã]) --> lb["Load balancer"]
    lb --> a1["catalog #1"]
    lb --> a2["catalog #2"]
    lb --> a3["catalog #3"]
    a1 --> redis[("Redis<br/>sessões, cache")]
    a2 --> redis
    a3 --> redis
    a1 --> pg[("PostgreSQL")]
    a2 --> pg
    a3 --> pg
    a3 --> s3[("Object store<br/>imagens, PDFs")]

As réplicas são caixas intercambiáveis; o estado fica nos armazenamentos compartilhados à direita. Cada tipo de estado que tende a "grudar" em um servidor tem uma nova casa padrão:

Este é o fator VI do Twelve-Factor App: "execute a aplicação como um ou mais processos stateless"¹. Isso não significa que o sistema não tenha estado — significa que o estado fica concentrado em poucos componentes construídos para guardá-lo, que você então escala com técnicas diferentes (réplicas, partições, caches: aulas 6 e 7).

/** Which routes are open, which need a valid token, which need the admin scope. */
@Bean
SecurityWebFilterChain security(ServerHttpSecurity http) {
    return http
            .csrf(ServerHttpSecurity.CsrfSpec::disable)        // stateless API, no cookies
            .authorizeExchange(ex -> ex
                    // open: getting a token, and the public keys to check one
                    .pathMatchers("/auth/register", "/auth/login", "/auth/.well-known/**").permitAll()
                    // open: browsing the catalog (HEAD is a GET without the body)
                    .pathMatchers(HttpMethod.GET, "/catalog/**").permitAll()
                    .pathMatchers(HttpMethod.HEAD, "/catalog/**").permitAll()
                    // admin only: changing the catalog (scope claim "user admin")
                    .pathMatchers("/catalog/**").hasAuthority("SCOPE_admin")
                    // health, metrics, routes: the edge never forwards /actuator from outside
                    .pathMatchers("/actuator/**").permitAll()
                    // everything else (and every future route): any valid token
                    .anyExchange().authenticated())
            .oauth2ResourceServer(oauth -> oauth.jwt(Customizer.withDefaults()))
            .build();
}

Escalar para cima ou para fora

Há duas formas de dar mais capacidade a um serviço:

App servers são escalados para fora quase por padrão, porque ser stateless torna isso trivial. Bancos de dados normalmente são escalados para cima primeiro, depois com réplicas e partições — é por isso que a camada de dados, e não a de aplicação, é onde a maioria dos gargalos acaba aparecendo.

Quantas réplicas?

A pergunta que todo design precisa responder com um número. Parta da capacidade de uma réplica, medida com um teste de carga (hands-on 2), e da carga de pico da sua estimativa (aula 2):

Por que uma utilização-alvo (tipicamente 50–70%)? Porque a latência não é linear na carga. À medida que um servidor se aproxima de 100% ocupado, as requisições começam a enfileirar e o tempo de espera explode — o "joelho" da curva (filas). O alvo deixa folga para rajadas e para a perda de uma réplica.

O gráfico abaixo deixa o joelho visível. Ele modela cada réplica como um servidor de 10 núcleos com 20 ms de trabalho por requisição (uma fila M/M/10) e distribui 4.000 requisições/s igualmente entre N réplicas:

Com 8 réplicas a fila cresce sem limite (100% ocupado). Com 9 réplicas (89% ocupadas) a latência média fica em torno de 31 ms — 60% acima dos 20 ms de trabalho real; a partir de cerca de 12 réplicas, adicionar mais quase não muda a média. E a cauda (p99) se degrada muito antes e muito mais rápido que a média (percentis) — mais um motivo para manter a utilização moderada.

Experimente no playground

Abra o cenário scale-out: um load balancer na frente de N réplicas da aplicação.

1. Rode o perfil load com 2 réplicas e anote o p99 e a taxa de erros.
2. Adicione réplicas uma de cada vez e observe o p99 cair até se estabilizar — o ponto em que a fila desaparece.
3. Coloque o caos em medium para matar réplicas aleatoriamente: os health checks tiram as réplicas mortas do pool, e as restantes só absorvem a carga se você deixou folga.

Abrir o simulador completo

O ciclo de vida de uma réplica

Escalar para fora significa que réplicas são criadas e destruídas o tempo todo — por deploys, pelo autoscaler, por falhas de nós. Uma réplica que se comporta bem durante seu ciclo de vida é tão importante quanto uma réplica stateless:

stateDiagram-v2
    [*] --> Starting : agendada em um nó
    Starting --> Ready : startup + readiness probe passam
    Ready --> NotReady : readiness falha (ex.: banco inacessível)
    NotReady --> Ready : readiness volta a passar
    Ready --> Draining : SIGTERM (deploy, scale-in)
    Draining --> [*] : requisições em andamento concluídas
    Ready --> [*] : crash / liveness falha → restart

• Inicie rápido, aqueça antes de receber tráfego. Um serviço na JVM pode precisar de vários segundos para iniciar; a readiness probe só deve passar quando os pools de conexão estiverem abertos e os caches aquecidos. Inicializações lentas tornam o autoscaling lento (serverless e autoscaling).
• Desligue de forma graciosa. Ao receber SIGTERM, pare de aceitar novas requisições, termine as que estão em andamento e só então saia. No Spring Boot, server.shutdown=graceful com spring.lifecycle.timeout-per-shutdown-phase=20s faz isso.
• Seja descartável (Twelve-Factor IX): nada importante deve depender de uma réplica viver muito tempo. Health checks (liveness, readiness, startup) são tratados em confiabilidade.

Formatos de computação

O mesmo serviço stateless pode rodar sobre substratos muito diferentes. A escolha muda quem gerencia o quê, quão rápido você escala e como você paga:

A aula 11 (cloud-native) cobre containers e Kubernetes em profundidade; esta aula cobre as decisões que dependem da carga de trabalho: serverless e autoscaling.

O mapa de conceitos de compute

Cada componente de computação responde onde um pedaço de lógica roda e como ele escala; os componentes externos são a lógica que você chama mas não executa. O mapa liga cada componente da paleta (verde) aos conceitos em que ele se apoia (azul):

flowchart LR
    app["app"]:::comp -.- c1["stateless, escala horizontal,<br/>ciclo de vida da réplica"]:::tech
    app -.- c2["REST, gRPC, GraphQL,<br/>APIs assíncronas"]:::tech
    app --> queue["queue"]:::comp
    queue --> worker["worker"]:::comp
    worker -.- c3["jobs idempotentes,<br/>lei de Little, DLQ"]:::tech
    scheduler["scheduler"]:::comp --> queue
    scheduler -.- c4["CronJob, locks,<br/>eleição de líder"]:::tech
    serverless["serverless"]:::comp -.- c5["cold start, concorrência,<br/>atraso do autoscaling"]:::tech
    app --> shared["auth · search ·<br/>notifications · analytics"]:::comp
    shared -.- c6["bounded contexts,<br/>alimentados por eventos, donos dos dados"]:::tech
    app --> ext["payment · email ·<br/>thirdparty"]:::comp
    ext -.- c7["idempotency keys, webhooks,<br/>reconciliação"]:::tech
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Relacionados

• Hands-on: hands-on 1 — primeiro serviço (a API REST do catalog e seu contrato OpenAPI), hands-on 3 — borda (três réplicas atrás do Nginx, medição de scale-out), hands-on 4 — gateway e identidade (uma porta de entrada para todos os serviços, o token verificado uma vez, nenhuma sessão nas réplicas), hands-on 7 — assíncrono (workers, outbox, consumidor idempotente), hands-on 9 — resiliência (order → payment com timeouts e circuit breaker), hands-on 10 — Kubernetes (HPA sob carga do k6).
• Exercícios: autoscaling no Kubernetes, orientado a eventos.
• Estudos de caso: ticketing (venda relâmpago da BoxOffice), sistema de pagamentos, sistema de notificações.
• Catálogo de componentes: compute e external.

Pontos-chave

O que quebra em seguida

Réplicas stateless são baratas de adicionar porque empurraram todo o estado para outro lugar, e para a BoxOffice esse lugar é o PostgreSQL: reservas, pedidos e usuários agora moram no único banco que todas as réplicas compartilham. Às 10:00 ele recebe cerca de 33.000 tentativas de reserva por segundo contra as ~1.100 que consegue atender, e dois fãs que clicam no lugar A-12 no mesmo milissegundo chegam a duas réplicas diferentes, então nenhum lock na memória de uma réplica protege o lugar. Escolher, usar e escalar o armazenamento que precisa dizer "um lugar, uma reserva" é a aula 6 — Bancos de dados.