Visão geral

São 09:59:58 de uma terça-feira. O BoxOffice anunciou que os ingressos de um show em estádio começam a ser vendidos às 10:00: 60 mil lugares, cerca de 2 milhões de fãs com a página aberta, muitos deles apertando "atualizar" a cada segundo. Às 10:00:00, todos os celulares enviam uma requisição ao mesmo tempo. A maioria dessas requisições nunca deveria chegar ao serviço inventory, que guarda os assentos — e as que chegam precisam alcançar uma réplica saudável, em uma ordem justa, vindas de fãs reais e não de bots de cambistas.

Tudo o que acontece entre o celular do fã e o primeiro serviço do BoxOffice é a borda (edge): resolução de nomes, entrega de conteúdo, filtragem de tráfego, load balancing e o API gateway. Esta aula trata desse caminho. Ele decide quão rápido chega o primeiro byte, quanta carga os serviços centrais recebem e se uma venda relâmpago é um sucesso ou uma queda de 10 minutos no jornal da noite.

Neste curso, a borda é o conjunto de componentes que recebem, filtram, roteiam e distribuem o tráfego antes que ele chegue aos serviços da aplicação. No simulador do curso eles formam a categoria TRAFFIC & EDGE da paleta: dns, cdn, waf, lb, apigw e ingress¹.

Roteiro

1. Esta visão geral — a jornada da requisição pela borda, reverse proxies, terminação TLS, um orçamento de latência e segurança na borda (WAF, bots, DDoS).
2. DNS & CDN — resolução de nomes, TTLs, GeoDNS e anycast; redes de entrega de conteúdo, cache keys, invalidação e edge compute.
3. Load Balancing — L4 vs L7, algoritmos, consistent hashing, service discovery, health checks e Kubernetes Ingress / Gateway API.
4. API Gateway & Rate Limiting — o que um gateway centraliza, o padrão BFF e os algoritmos de rate limiting.
5. Identidade: OAuth 2.1, OIDC & JWT — quem é o chamador: tokens emitidos por auth e validados uma vez, no gateway.
6. Protocolos — HTTP/1.1, HTTP/2, HTTP/3 e QUIC, TLS 1.3, WebSockets, SSE e gRPC.
7. Quiz — teste o 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 jornada da requisição

Um fã abre https://boxoffice.com/events/stadium-show e toca em "Escolher assentos". Antes de qualquer código Java rodar, a requisição atravessa vários componentes, cada um com uma tarefa precisa. Aperte play e acompanhe:

sequenceDiagram
    participant F as Celular do fã
    participant D as DNS
    participant C as Borda da CDN
    participant W as WAF
    participant L as Load balancer
    participant G as API gateway
    participant I as Ingress
    participant S as serviço inventory
    F->>D: boxoffice.com? (A/AAAA)
    D-->>F: 203.0.113.10 (borda mais próxima, TTL 60 s)
    F->>C: GET /events/stadium-show (TLS)
    C-->>F: HTML, JS, imagens do cache da borda
    F->>C: GET /api/events/42/seats
    C->>W: cache miss: encaminha à origem
    W->>L: requisição passou pelas regras (não é bot)
    L->>G: escolhe uma réplica saudável do gateway
    G->>I: token válido, dentro do rate limit
    I->>S: roteia /api/events/** para inventory
    S-->>F: mapa de assentos (JSON)

Leia o diagrama como uma série de decisões, tomadas o mais cedo (e da forma mais barata) possível:

1. O DNS decide para onde o cliente vai: qual endereço IP, qual região, qual localidade de borda.
2. A CDN (Content Delivery Network) decide se a requisição precisa ir adiante: se a resposta está em cache na borda, a jornada termina aqui, a poucos milissegundos do fã.
3. O WAF (Web Application Firewall) decide se a requisição é permitida: tráfego malformado, malicioso ou abusivo é descartado aqui.
4. O load balancer decide qual réplica atende a requisição, e só a envia para réplicas saudáveis.
5. O API gateway decide se o chamador é permitido e está dentro da sua cota: autenticação, rate limits, roteamento para o serviço certo.
6. O ingress (dentro do Kubernetes) decide qual Service do cluster recebe a requisição, por host e path.

Cada salto remove trabalho do seguinte. Em uma venda relâmpago bem projetada, a grande maioria das requisições termina na CDN (assets estáticos, a página do evento, até um mapa de assentos em cache por um segundo), muitos bots terminam no WAF, e só um fluxo controlado e justo chega ao inventory.

Implantações reais juntam algumas dessas caixas. Cloudflare ou CloudFront combinam DNS, CDN, WAF e proteção contra DDoS em um único produto; um AWS Application Load Balancer pode terminar TLS e rotear por path, fazendo parte do trabalho do gateway; no Kubernetes, o ingress controller muitas vezes é o load balancer L7. Em uma entrevista, desenhe primeiro as responsabilidades como caixas separadas; depois diga quais delas um único produto cobre.

Reverse proxies

Quase toda caixa da borda é um reverse proxy: um servidor que recebe requisições em nome de outros servidores, as encaminha e devolve a resposta como se fosse sua. O cliente só conhece o endereço do proxy; os backends ficam escondidos em uma rede privada.

flowchart LR
    c1([Fã 1]) --> rp["Reverse proxy<br/>boxoffice.com:443"]
    c2([Fã 2]) --> rp
    c3([Bot]) -.->|bloqueado| rp
    rp --> a1[réplica 1 do gateway]
    rp --> a2[réplica 2 do gateway]
    rp --> a3[réplica 3 do gateway]

Como toda requisição passa por ele, um reverse proxy é o lugar natural para colocar preocupações transversais uma única vez, em vez de em cada serviço:

O oposto, um forward proxy, fica na frente dos clientes (um proxy corporativo, por exemplo). Na borda, só nos interessam os reverse proxies.

Onde o TLS termina

O TLS (Transport Layer Security) criptografa o tráfego entre dois pontos. Na borda, há três escolhas comuns de onde a conexão criptografada termina:

Arquiteturas modernas seguem uma postura zero trust: terminar o TLS público na borda e criptografar de novo dentro do cluster — frequentemente de forma automática, com TLS mútuo (mTLS) de um service mesh (veja Rede & Segurança).

Um orçamento de latência para a borda

Cada salto adiciona tempo. Suponha que o BoxOffice queira que a API do mapa de assentos responda em menos de 200 ms no p99 para fãs no Brasil. Para onde vai o tempo? Os valores abaixo são suposições ilustrativas para um usuário em São Paulo e uma região em São Paulo; o método importa mais que os números.

Três lições saem desse tipo de tabela:

• Estabelecer conexões é caro e evitável. Cache de DNS, keep-alive e retomada de sessão TLS removem cerca de um terço do custo frio. O HTTP/3 remove ainda mais (Protocolos).
• A distância domina. Se a origem estivesse na Virgínia em vez de São Paulo, cada round trip custaria cerca de 120 ms em vez de 10 ms, e uma requisição fria pagaria vários deles. É por isso que existem CDNs e localidades de borda.
• A requisição mais barata é a que nunca chega à origem. Um cache hit na borda responde no tempo de um RTT até o ponto de presença mais próximo.

Segurança na borda: WAF, bots e DDoS

No dia da venda, o BoxOffice não recebe só fãs. Recebe bots de cambistas que tentam pegar os melhores assentos no primeiro segundo, scripts de credential stuffing que testam senhas vazadas contra /login e, possivelmente, um ataque DDoS (Distributed Denial of Service) de alguém que quer que a venda fracasse. A borda é o primeiro e mais barato lugar para deter todos eles, porque vê todo o tráfego antes que ele custe qualquer coisa ao núcleo.

Web Application Firewall (WAF)

Um WAF inspeciona requisições HTTP (L7) e bloqueia as que casam com regras. As regras vêm em três famílias:

• Conjuntos de regras gerenciadas que detectam ataques comuns — SQL injection, cross-site scripting (XSS), path traversal, endpoints vulneráveis conhecidos. A referência é o OWASP Core Rule Set (CRS), usado pelo ModSecurity e pelo Coraza e espelhado pelos WAFs de nuvem².
• Regras de reputação: bloquear ou desafiar endereços IP de botnets conhecidas, proxies de anonimização ou faixas de data center que fãs reais não usam.
• Regras customizadas para a sua aplicação: "no máximo 5 POST /login por IP por minuto", "só permitir PUT /holds com um token válido da sala de espera", "bloquear requisições sem User-Agent".

As regras de WAF começam em modo count (só registro), são ajustadas contra tráfego real para remover falsos positivos e só então passam para block. Um WAF que bloqueia fãs reais durante a venda é pior que nenhum WAF.

Mitigação de bots

Nem todo bot é ruim (crawlers de buscadores, monitores de uptime), e os ruins se parecem cada vez mais com humanos. A mitigação combina vários sinais, dos mais baratos primeiro:

A sala de espera merece menção especial no BoxOffice: quando 2 milhões de fãs chegam para 60 mil assentos, deixar todos entrarem no mapa de assentos de uma vez garante uma queda e premia quem for mais rápido — geralmente um bot. Uma sala de espera na borda entrega a cada visitante um token assinado com uma posição e admite, digamos, 1.000 usuários por segundo no fluxo de compra — a taxa que o inventory sustenta na aula de estimativas. O núcleo vê uma carga estável e dimensionada; o resto dos fãs vê uma barra de progresso servida pela CDN. Você vai modelá-la com uma fila na aula de mensageria e no estudo de caso de ingressos.

DDoS

Um ataque de negação de serviço tenta esgotar um recurso — banda, conexões, CPU — para que usuários legítimos não possam ser atendidos. "Distribuído" significa que ele vem de muitas origens ao mesmo tempo (uma botnet), então bloquear um único IP não adianta³.

A ideia-chave é a assimetria: você não consegue superar um atacante em capacidade com seus próprios servidores, mas um grande provedor de CDN/DDoS tem mais capacidade de borda que qualquer ataque isolado. Com anycast, o mesmo endereço IP é anunciado a partir de todas as localidades de borda, então o tráfego de cada bot vai para a localidade mais próxima e a inundação se divide entre todas elas (DNS & CDN). Ataques volumétricos são, portanto, um problema para o qual você compra uma solução (AWS Shield, Cloud Armor, Azure DDoS Protection, Cloudflare)⁴; ataques L7 são um problema para o qual você também precisa projetar — endpoints caros precisam ser cacheáveis, ter rate limit ou ser protegidos por um desafio.

Experimente. Carregue o cenário de venda relâmpago e aperte Run. O desenho, como está, não tem CDN, gateway nem sala de espera — só users → lb → app → inventory-db, com os compradores também chamando o payment provider (cota de 500 req/s). Quando a venda abre (t = 60 s), o tráfego salta 20×: o app satura e os erros e o p99 explodem; aumente as réplicas dele e o gargalo só se desloca para o inventory-db e o provedor de pagamento. Depois abra no playground completo (↗) e siga as dicas — uma CDN na frente, um cache para as leituras do catálogo e um API gateway que envia os compradores para uma fila de sala de espera drenada por workers order — ou aperte Mostrar uma solução possível. Compare a latência p99, a taxa de erros e as req/s atendidas, e leia o consumer lag: é quanto tempo um comprador espera na fila.

Abrir o playground completo

O mapa de conceitos da borda

Cada componente da borda responde a uma pergunta e entrega a requisição ao seguinte. O mapa liga cada componente da paleta (verde) aos conceitos em que ele se apoia (azul) e à subpágina ou aula que os ensina:

flowchart LR
    client["client · mobile"]:::comp --> dns["dns"]:::comp
    dns --> cdn["cdn"]:::comp
    cdn --> waf["waf"]:::comp
    waf --> lb["lb"]:::comp
    lb --> apigw["apigw"]:::comp
    apigw --> ingress["ingress"]:::comp
    ingress --> app["serviços da app"]:::comp
    dns -.- c1["TTL, GeoDNS, anycast,<br/>failover de DNS"]:::tech
    cdn -.- c2["cache keys, Cache-Control,<br/>hit ratio, micro-caching"]:::tech
    waf -.- c3["regras OWASP, bots,<br/>sala de espera, DDoS"]:::tech
    lb -.- c4["L4/L7, algoritmos,<br/>consistent hashing, health checks"]:::tech
    apigw -.- c5["offload de autenticação, rate limiting,<br/>BFF"]:::tech
    ingress -.- c6["Ingress, Gateway API,<br/>service discovery"]:::tech
    c1 -.- d1["consistência eventual<br/>(aula 3)"]
    c2 -.- d2["padrões de cache<br/>(aula 7)"]
    c4 -.- d3["serviços stateless,<br/>autoscaling (aula 5)"]
    c5 -.- d4["identidade, JWT<br/>(Identidade, esta aula)"]
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Pontos-chave

O que quebra em seguida

A borda decide qual réplica atende cada requisição, e o gateway confere o token do chamador uma vez para todos os serviços — mas ambos assumem algo que não conseguem garantir: que qualquer réplica pode atender qualquer requisição. Uma réplica que guarda a sessão do fã ou uma reserva de assento na própria memória a perde quando morre, ou quando a próxima requisição cai em outra réplica. O lab 3 mostra o outro limite: três réplicas de catalog atrás do Nginx multiplicam as requisições baratas, mas não a carga mista, em que o PostgreSQL é o gargalo (em uma execução de teste, db a ~670% de CPU e cada réplica a ~20%). O que uma réplica precisa ser (stateless), como os serviços são recortados e o gateway que o lab 4 constrói com auth atrás desta borda estão na aula 5 — Compute & Services.

Relacionados

• Hands-on 3 — Edge: reverse proxy e load balancer Nginx sobre 3 réplicas, health checks e rate limiting, medidos com k6.
• Hands-on 4 — Gateway & identidade: Spring Cloud Gateway com validação de JWT.
• Exercício — Design no playground: resolva desafios do playground com metas de SLO e custo.
• Estudos de caso: Rate limiter e Ingressos (venda relâmpago do BoxOffice).
• System Design Playground e o catálogo de componentes — Traffic & Edge.
• Preparação para entrevistas.
• Aula anterior: Sistemas Distribuídos. Próxima aula: Compute & Services. A borda volta em Caching, Confiabilidade e Rede & Segurança.