Escalabilidade nos servidores
pela lente da F1.

Laboratório

1. Linha de base: uma instância, capacidade 2, 100 ms por requisição.

docker run -d --name base -p 8081:8080 lab-app
curl -s -o /dev/null -w "latência de uma requisição: %{time_total}s\n" localhost:8081/
carga http://localhost:8081/

Saída esperada (valores aproximados, sua máquina varia):

latência de uma requisição: 0.10xxxxs
real    0m5.2s

A conta: 2 requisições a cada 100 ms dão 20 por segundo; 100 requisições levam cerca de 5 segundos.

2. Otimização: mesma máquina, trabalho pela metade.

docker run -d --name otim -p 8082:8080 -e TRABALHO_MS=50 lab-app
curl -s -o /dev/null -w "latência: %{time_total}s\n" localhost:8082/
carga http://localhost:8082/

Esperado: latência perto de 0.05s e tempo total perto de 2,5 s.

3. Escala vertical: um "servidor maior" (capacidade 4).

docker run -d --name vert -p 8083:8080 -e CAPACIDADE=4 lab-app
curl -s -o /dev/null -w "latência: %{time_total}s\n" localhost:8083/
carga http://localhost:8083/

Esperado: latência continua perto de 0.10s; tempo total perto de 2,5 s.

4. Escala horizontal: três instâncias pequenas, com um "balanceador" feito à mão.

docker run -d --name h1 -p 8084:8080 lab-app
docker run -d --name h2 -p 8085:8080 lab-app
docker run -d --name h3 -p 8086:8080 lab-app
 
# O módulo 3 do número da requisição escolhe a porta 8084, 8085 ou 8086
time (seq 1 100 | xargs -P 20 -I{} sh -c 'curl -s -o /dev/null http://localhost:$((8084 + {} % 3))/')

Esperado: tempo total perto de 1,7 s (3 instâncias × 20 por segundo = 60 por segundo).

5. O que observar.

Escalar (vertical ou horizontalmente) não mexeu na latência de uma requisição isolada, só no throughput. Otimizar mexeu nos dois. É exatamente a distinção entre desempenho e escalabilidade.

6. O ponto único de falha, ao vivo.

docker stop base
curl -s -o /dev/null -w "%{http_code}\n" --max-time 2 localhost:8081/
 
docker stop h1
for p in 8084 8085 8086; do curl -s -o /dev/null -w "%{http_code} " --max-time 2 localhost:$p/; done; echo

Esperado: 000 na primeira chamada (conexão recusada: o SPOF caiu) e 000 200 200 na segunda. Com a frota, só um terço falha. Mas quem decide para onde mandar a requisição ainda é o seu sh -c, que não sabe que h1 caiu. Na próxima etapa, quem decide é o load balancer.

Limpeza:

docker rm -f base otim vert h1 h2 h3

Exercícios

1. Escalar ou otimizar? Para cada situação, diga qual alavanca usar primeiro e por quê: (a) uma página faz 400 consultas SQL em loop; (b) o site da campanha de Black Friday vai receber 20 vezes o tráfego normal em 3 horas; (c) um sistema interno de 50 funcionários está lento às segundas de manhã. *Resposta esperada:* (a) otimizar, porque o problema é a query e escalar só multiplicaria o desperdício; (b) escalar horizontalmente, de preferência com autoscaling agendado ou por métrica; (c) medir antes, provavelmente otimizar, e evitar autoscaling por ser exagero de custo e complexidade.
2. Escreva as três regras. Para uma loja com pico previsível às 20h, escreva uma regra baseada em métrica, uma agendada e descreva o que uma preditiva faria de diferente. *Resposta esperada:* (métrica) "se a CPU média da frota passar de 70% por mais de 5 minutos, adicione um servidor; se cair abaixo de 30% por 10 minutos, remova um"; (agendada) "todo dia às 19h50, suba para o número de servidores que o pico pede, e às 22h desça para o mínimo"; (preditiva) um modelo de Machine Learning treinado no histórico aprende o formato do pico (por exemplo, que sexta-feira é mais forte que terça) e sobe a capacidade antes de ele começar, sem depender de um horário escrito à mão. A diferença de fundo: a regra por métrica reage depois que a carga subiu; a agendada e a preditiva se antecipam.
3. Triângulo. Você precisa baixar a latência do banco pela metade. Cite uma solução que sacrifica custo e outra que sacrifica complexidade. *Resposta esperada:* sacrificando custo, hardware de ponta para o banco (escala vertical: mais RAM, discos mais rápidos), simples de operar, mas caro, com teto e ponto único de falha; sacrificando complexidade, uma ou mais camadas de cache (por exemplo, Redis) na frente do banco, baratas por unidade, mas com novos problemas (invalidação, dado desatualizado). Antes das duas, vale conferir se uma query ou um índice melhor já resolve, porque a otimização custa pouco nos três vértices.

Laboratório

1. Round-robin. 30 requisições, contando quem respondeu:

for i in $(seq 1 30); do curl -s localhost:8080/; done | awk '{print $1}' | sort | uniq -c

Esperado (os IDs mudam):

     10 3f2a1b9c0d1e
     10 7c8d9e0f1a2b
     10 a1b2c3d4e5f6

Graças à diretiva zone, os processos worker do Nginx compartilham o mesmo contador de round-robin, por isso a divisão sai exata. Sem ela, cada worker teria o seu contador e a distribuição poderia sair irregular (por exemplo, 12 para um e 9 para cada um dos outros).

2. Failover. Derrube uma réplica e continue chamando:

docker stop $(docker compose ps -q app | head -n 1)
for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code}\n" localhost:8080/; done | sort | uniq -c

Esperado: 20 200. Nenhuma falha chegou ao cliente. A primeira requisição que cair na réplica parada pode demorar cerca de 1 segundo (o proxy_connect_timeout) antes de o Nginx tentar outro servidor. Compare com a Etapa 01, em que apareceu 000.

Traga a réplica de volta e atualize o Nginx, que resolve nomes só na partida e por isso pode estar com um IP desatualizado:

docker compose up -d
docker compose exec lb nginx -s reload

3. Algoritmos. Troque para least_conn e depois para ip_hash. (No macOS, use gsed no lugar de sed, ou edite nginx/default.conf à mão: insira a linha least_conn; logo abaixo de upstream azul { e, depois, troque-a por ip_hash;.)

# Insere "least_conn;" logo depois da abertura do bloco upstream azul
sed -i 's/upstream azul {/upstream azul {\n    least_conn;/' nginx/default.conf
docker compose exec lb nginx -t && docker compose exec lb nginx -s reload
 
# Agora troca por ip_hash
sed -i 's/least_conn;/ip_hash;/' nginx/default.conf
docker compose exec lb nginx -t && docker compose exec lb nginx -s reload
for i in $(seq 1 10); do curl -s localhost:8080/; done | awk '{print $1}' | sort | uniq -c

Esperado com ip_hash: uma única linha com 10 e um só servidor. O seu cliente tem sempre o mesmo IP (o do gateway do Docker) e por isso cai sempre no mesmo servidor: é a afinidade de sessão, e também o desequilíbrio que acontece quando muita gente compartilha um IP. Remova a linha para voltar ao round-robin:

sed -i '/ip_hash;/d' nginx/default.conf
docker compose exec lb nginx -s reload

4. Canary com 10%. Substitua o conteúdo de nginx/default.conf por:

upstream azul {
    zone azul 64k;                      # estado de balanceamento compartilhado entre os workers
    server app:8080 max_fails=1 fail_timeout=10s;
}
 
upstream verde {
    server verde:8080;
}
 
# Sorteia o destino pelo ID único de cada requisição: 10% vão para "verde", o resto para "azul"
split_clients "${request_id}" $destino {
    10% verde;
    *   azul;
}
 
server {
    listen 80;
    location / {
        proxy_pass http://$destino;     # o nome do grupo vem da variável sorteada
        proxy_connect_timeout 1s;
        proxy_next_upstream error timeout;
    }
}

docker compose exec lb nginx -t && docker compose exec lb nginx -s reload
seq 1 200 | xargs -P 10 -I{} curl -s localhost:8080/ | awk '{print $2}' | sort | uniq -c

Esperado, aproximadamente: 180 v1 e 20 v2 (o sorteio varia um pouco). Se as métricas da v2 piorassem, só esses 10% teriam sentido.

5. Blue/Green: a virada e o rollback. (No macOS, use gsed, ou edite o arquivo à mão: troque 10% por 100% na virada e apague a linha do verde no rollback.)

# Virada: 100% para a versão nova
sed -i 's/10% verde;/100% verde;/' nginx/default.conf
docker compose exec lb nginx -s reload
for i in 1 2 3 4 5; do curl -s localhost:8080/ | awk '{print $2}'; done
# Esperado: v2 cinco vezes
 
# Rollback: remove a regra do verde e volta tudo para azul
sed -i '/% verde;/d' nginx/default.conf
docker compose exec lb nginx -s reload
for i in 1 2 3 4 5; do curl -s localhost:8080/ | awk '{print $2}'; done
# Esperado: v1 cinco vezes

O nginx -s reload é gracioso: os processos antigos terminam as conexões em andamento antes de sair. É a ideia do connection draining.

Exercícios

Os exercícios 1 e 2 mexem no nginx/default.conf com a stack no ar. O arquivo está no formato do canary/rollback (com o split_clients), e é o bloco location / dele que você troca no exercício 1. Depois de editar, rode docker compose exec lb nginx -t && docker compose exec lb nginx -s reload.

1. Roteamento L7. Troque o bloco location / por dois: location /api/ com proxy_pass http://verde; e location / com proxy_pass http://azul;. Chame curl -s localhost:8080/api/pagamentos e curl -s localhost:8080/blog. Qual versão responde a cada uma? Por que isso só é possível em L7? *Resposta esperada:* /api/pagamentos responde com v2 (o grupo verde) e /blog com v1 (o grupo azul). Só o L7 consegue, porque o caminho /api/... está dentro da requisição HTTP, e o L4 enxerga apenas IP e porta.
2. Pesos. Qual seria o efeito de server app:8080 weight=3; ao lado de outro servidor com peso 1, e em que cenário real você usaria isso? *Resposta esperada:* o servidor de peso 3 receberia cerca de 3 de cada 4 requisições (proporção 3 para 1). É o Weighted Round-robin, útil quando as máquinas são desiguais e um servidor mais potente deve receber mais carga que um menor.
3. Ingress (leitura). No YAML do segundo exemplo comentado, qual serviço atende /api/pedidos e qual atende /? *Resposta esperada:* /api/pedidos vai para o Service api; / vai para o web. É o mesmo raciocínio dos blocos location do Nginx.

Limpeza (ao terminar o laboratório e os exercícios):

docker compose down -v
cd ..

Laboratório

1. O problema: carrinho stateful.

export MODO=memoria
docker compose up -d --build
 
# Três itens, um por requisição; o LB distribui entre as réplicas
for i in 1 2 3; do curl -s -X POST "localhost:8080/carrinho?user=ana&item=item$i"; done
# Agora lê o carrinho três vezes
for i in 1 2 3; do curl -s "localhost:8080/carrinho?user=ana"; done

Esperado (os IDs e a ordem variam):

{"servidor": "aaa111", "modo": "memoria", "user": "ana", "itens": ["item1"]}
{"servidor": "bbb222", "modo": "memoria", "user": "ana", "itens": ["item2"]}
{"servidor": "ccc333", "modo": "memoria", "user": "ana", "itens": ["item3"]}

Cada resposta tem um item só. O carrinho da Ana está espalhado em três memórias e nenhuma réplica o vê por inteiro. É o problema do estado preso ao servidor. (O zone no upstream faz os workers do Nginx compartilharem o round-robin, então as seis requisições percorrem as três réplicas em ordem e cada leitura cai na réplica que recebeu o item correspondente.)

2. A solução: estado no Redis.

docker compose down
export MODO=redis
docker compose up -d
for i in 1 2 3; do curl -s -X POST "localhost:8080/carrinho?user=ana&item=item$i"; done
for i in 1 2 3; do curl -s "localhost:8080/carrinho?user=ana"; done
docker compose exec redis redis-cli LRANGE carrinho:ana 0 -1

Esperado: as três respostas mostram "itens": ["item1", "item2", "item3"], vindas de servidores diferentes, e o redis-cli lista:

1) "item1"
2) "item2"
3) "item3"

3. Failover sem perder o carrinho.

docker stop $(docker compose ps -q app | head -n 1)
curl -s "localhost:8080/carrinho?user=ana"

Esperado: o carrinho continua completo. Pode levar até cerca de 1 segundo se a requisição cair na réplica parada: o Nginx de código aberto só percebe a falha ao tentar, e o proxy_connect_timeout 1s limita a espera antes de ele passar para outra réplica. Suba a réplica de volta e atualize o Nginx, que resolve nomes só na partida (a réplica pode voltar com outro IP):

docker compose up -d
docker compose exec lb nginx -s reload

4. Fila e workers. O pedido volta rápido e o trabalho pesado acontece depois:

# Liga 1 worker (o MODO continua exportado, para não recriar a API em outro modo)
docker compose up -d --scale worker=1
 
# Enfileira 12 pedidos; cada resposta chega na hora com 202
for i in $(seq 1 12); do curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" -X POST "localhost:8080/pedido?id=$i"; done
 
# Tamanho da fila
docker compose exec redis redis-cli LLEN fila:pedidos

Esperado: doze linhas do tipo 202 0.00xs e um (integer) N com N entre 1 e 11, porque o worker já está consumindo. Veja o worker trabalhando (Ctrl+C para sair):

docker compose logs -f worker

Saída esperada (resumida):

lab-etapa-03-worker-1  | [9f8e7d6c5b4a] processando pedido 1
lab-etapa-03-worker-1  | [9f8e7d6c5b4a] pedido 1 concluido

5. Escalar os workers pelo tamanho da fila. Espere a fila do passo anterior esvaziar (LLEN igual a 0, cerca de 12 s) para a medição não somar pedidos antigos. Depois meça o tempo para esvaziar a fila com 1 worker e com 3:

# Com 1 worker (12 pedidos de 1 s: perto de 12 s)
for i in $(seq 1 12); do curl -s -o /dev/null -X POST "localhost:8080/pedido?id=$i"; done
time { while [ "$(docker compose exec -T redis redis-cli LLEN fila:pedidos | tr -d '\r')" != "0" ]; do sleep 0.5; done; }
 
# Com 3 workers (perto de 4 s)
docker compose up -d --scale worker=3
for i in $(seq 1 12); do curl -s -o /dev/null -X POST "localhost:8080/pedido?id=$i"; done
time { while [ "$(docker compose exec -T redis redis-cli LLEN fila:pedidos | tr -d '\r')" != "0" ]; do sleep 0.5; done; }

Os workers escalaram independentemente da API, e foi o tamanho da fila que justificou o escalonamento. É a ideia do KEDA.

Exercícios

Os exercícios 1 e 3 precisam da stack no ar: export MODO=redis no exercício 1 e export MODO=memoria no exercício 3. Para trocar de modo, rode docker compose down, exporte o novo valor e docker compose up -d.

1. KEDA à mão. Suponha que cada worker processa 1 pedido por segundo e você quer esvaziar a fila em até 4 segundos. Escreva a fórmula do número de workers em função do LLEN (arredonde para cima) e teste com --scale. *Resposta esperada:* workers = ceil(LLEN / 4), porque cada worker dá conta de 4 pedidos em 4 segundos. Em Bash, n=$(( (LLEN + 3) / 4 )). Com LLEN igual a 12, são 3 workers (docker compose up -d --scale worker=3) e a fila esvazia em cerca de 4 segundos. É a lógica que o KEDA automatiza.
2. Retry com backoff exponencial. Rode o script abaixo contra uma porta onde nada escuta. Durante a espera, em outro terminal, suba docker run -d --rm -p 9999:8080 lab-app e veja o script ter sucesso.

   for tentativa in 1 2 3 4 5; do
     # --fail trata HTTP de erro como falha; --max-time 2 limita a espera de cada tentativa
     if curl -sf --max-time 2 -o /dev/null http://localhost:9999/health; then
       echo "ok na tentativa $tentativa"; break
     fi
     espera=$((2 ** (tentativa - 1)))   # espera 1, 2, 4, 8, 16 segundos
     echo "tentativa $tentativa falhou, esperando ${espera}s"
     sleep "$espera"
   done

   *Resposta esperada:* linhas como tentativa 1 falhou, esperando 1s, tentativa 2 falhou, esperando 2s, e assim por diante, até aparecer ok na tentativa N na primeira tentativa depois de o container subir. O intervalo dobra a cada falha, então o script insiste sem martelar o serviço. Se você não subir o container, as cinco tentativas falham e o script termina sem a linha de ok. Ao final, pare o container de teste com docker stop $(docker ps -q --filter publish=9999).
3. Sticky session, o remendo. Com a stack em MODO=memoria, adicione ip_hash; ao upstream backend em nginx/default.conf (logo abaixo da linha upstream backend {), rode docker compose exec lb nginx -s reload e repita o teste do carrinho do passo 1 com um usuário novo (por exemplo, user=bia). Funciona? Agora derrube a réplica que atendeu (o campo "servidor" da resposta é o ID curto do container: docker stop ID) e leia o carrinho de novo. O que aconteceu, e por que isso limita a resiliência? *Resposta esperada:* com ip_hash, todas as requisições do seu cliente (sempre o mesmo IP) caem na mesma réplica, então as três leituras mostram ["item1", "item2", "item3"], sempre com o mesmo "servidor": o remendo funciona enquanto essa réplica vive. Depois do docker stop, a próxima leitura é desviada para outra réplica (possivelmente com cerca de 1 s de espera) e volta com "itens": []. O carrinho morava na memória da réplica que caiu e morreu com ela. A sticky session não tira o estado do servidor, só esconde o problema: a falha de uma instância continua perdendo dados dos clientes presos a ela, e a carga se distribui pelo IP, não pela capacidade. Ao terminar, apague a linha ip_hash;, rode docker compose up -d para recriar a réplica e docker compose exec lb nginx -s reload.
4. ReplicaSet (leitura). No YAML do segundo exemplo comentado, mapeie cada campo ao Compose: quem é o replicas, quem é a imagem, e o que não tem equivalente direto? *Resposta esperada:* spec.replicas: 3 corresponde a deploy.replicas: 3; o image dentro de template.spec.containers corresponde ao image: do serviço; o template inteiro é o molde, como a definição de um serviço no Compose; metadata.name faz o papel do nome do serviço; containerPort: 80 documenta a porta, como o EXPOSE do Dockerfile. O selector com matchLabels não tem equivalente que você escreva no Compose: ali as réplicas são agrupadas pelo nome do serviço, enquanto no Kubernetes o ReplicaSet encontra "os seus" Pods pelo rótulo app: carrinho.

Limpeza (ao terminar o laboratório e os exercícios):

docker compose down -v
unset MODO
cd ..

Laboratório

1. Detetive de performance na origem. Inspecione os cabeçalhos:

curl -sI http://localhost:8082/estatico/app.js

Esperado (resumido):

HTTP/1.1 200 OK
...
ETag: "6650a1b2-14"
Cache-Control: public, max-age=10

2. O 304 acontecendo. Pegue o ETag e pergunte "mudou?":

ETAG=$(curl -sI http://localhost:8082/estatico/app.js | tr -d '\r' | awk 'tolower($1)=="etag:" {print $2}')
curl -sI -H "If-None-Match: $ETAG" http://localhost:8082/estatico/app.js

Esperado: HTTP/1.1 304 Not Modified, sem corpo. O servidor confirmou que a cópia ainda vale sem reenviar o arquivo.

3. Miss e hit na borda.

for i in 1 2 3; do curl -s -D - -o /dev/null http://localhost:8081/estatico/app.js | tr -d '\r' | grep -i '^x-cache'; done

Esperado:

X-Cache: MISS
X-Cache: HIT
X-Cache: HIT

4. Cache Hit Ratio. Vinte requisições e a contagem:

for i in $(seq 1 20); do curl -s -D - -o /dev/null http://localhost:8081/estatico/app.js | tr -d '\r' | grep -i '^x-cache'; done | sort | uniq -c

Esperado: 20 X-Cache: HIT se você rodou logo depois do passo 3 (dentro dos 10 s de TTL). Se já passaram mais de 10 s, o resultado é 1 X-Cache: REVALIDATED e 19 X-Cache: HIT: a borda já tem a cópia, então a primeira resposta depois do TTL revalida com a origem, e MISS não aparece (o MISS só acontece quando a borda não tem nada guardado, como no passo 3). Conte o REVALIDATED como uma ida à origem: o hit ratio fica em 20 de 20 (100%) ou 19 de 20 (95%). Confirme que a origem quase não foi incomodada:

docker compose logs origem | grep 'app.js' | wc -l

Esperado: 4 ou 5. A conta é esta:

• 3 linhas dos curl -sI que você mandou direto à origem, na porta 8082 (uma no passo 1 e duas no passo 2);
• 1 linha da borda, o MISS do passo 3;
• mais 1 linha só se o TTL venceu e houve revalidação (o 304).

O que importa: das 20 requisições deste passo, a origem viu no máximo uma.

5. Expiração e revalidação. Espere o TTL passar e peça de novo:

sleep 11
curl -s -D - -o /dev/null http://localhost:8081/estatico/app.js | tr -d '\r' | grep -i '^x-cache'
docker compose logs origem | grep 'app.js' | tail -n 3

Esperado: X-Cache: REVALIDATED e, nos logs da origem, uma linha com 304. A borda perguntou, a origem respondeu "não mudou" e o TTL foi renovado sem transferir o arquivo.

6. Arquivo que mudou: expira e baixa de novo.

echo 'console.log("v2");' > site/estatico/app.js
curl -s http://localhost:8081/estatico/app.js      # ainda v1, dentro do TTL
sleep 11
curl -s -D - http://localhost:8081/estatico/app.js | tr -d '\r' | grep -iE '^x-cache|console'

Esperado: a primeira chamada mostra console.log("v1"); (cópia da borda, ainda válida). Depois do TTL, aparecem X-Cache: EXPIRED e console.log("v2");. Entre a mudança e o fim do TTL, os usuários viram a versão antiga: é a janela de defasagem que todo TTL aceita. Se a primeira chamada já mostrar v2, o TTL do passo anterior tinha vencido; repita o passo com uma nova edição.

7. Invalidação (purge) simulada. O Nginx de código aberto não tem API de purge; simulamos apagando o cache. Primeiro encha o cache, depois "invalide":

echo 'console.log("v3");' > site/estatico/app.js
curl -s http://localhost:8081/estatico/app.js        # v2 ou v3, conforme o estado do cache
docker compose exec edge sh -c 'rm -rf /var/cache/nginx/edge/*'
docker compose restart edge
curl -s -D - http://localhost:8081/estatico/app.js | tr -d '\r' | grep -iE '^x-cache|console'

Esperado: X-Cache: MISS e console.log("v3");, na hora, sem esperar o TTL. Uma CDN real faz isso por API ou painel, e é por isso que invalidar demais custa eficiência: cada purge obriga um novo miss.

Exercícios

Os exercícios 1 e 2 precisam da stack no ar. Depois de editar origem/default.conf, rode docker compose exec origem nginx -s reload.

1. Cachear a API. Em origem/default.conf, adicione add_header Cache-Control "public, max-age=60"; no location /api/ e recarregue. Faça 10 chamadas a localhost:8081/api/produtos antes e depois da mudança, olhando o X-Cache. O que muda? Que tipo de resposta de API é segura de cachear assim? *Resposta esperada:* antes, as 10 chamadas aparecem como MISS, porque a resposta não traz Cache-Control e a borda não a guarda (a origem é consultada toda vez); depois, a primeira é MISS e as 9 seguintes são HIT (dentro dos 60 s). É seguro para respostas GET públicas, iguais para todos os usuários e que mudam pouco, como o catálogo de produtos; não serve para respostas personalizadas.
2. Quando não cachear. Troque o valor por Cache-Control "private, no-store". O X-Cache volta a ser HIT? Por que dados de um usuário logado não deveriam ficar numa borda compartilhada? *Resposta esperada:* não. Depois que a cópia de 60 s do exercício anterior expirar (ou for apagada, como no passo 7), as chamadas voltam a ser MISS, porque no-store proíbe a borda de guardar a resposta. Dados de um usuário logado numa borda compartilhada poderiam ser entregues a outra pessoa, e private indica que só o navegador do próprio usuário pode guardá-los.
3. Quanto cachear? Para cada item, escolha um TTL e justifique: logo da empresa, bundle JavaScript versionado, catálogo de produtos, saldo bancário do usuário. *Resposta esperada (exemplos):* logo da empresa, TTL longo (dias), porque quase nunca muda; bundle JavaScript versionado, TTL muito longo (meses), porque o nome do arquivo muda a cada versão e a cópia nunca fica velha; catálogo de produtos, TTL curto (de segundos a poucos minutos), aceitando uma pequena defasagem; saldo bancário, não cachear (private, no-store), porque é dado pessoal e muda o tempo todo.
4. Conceitual. Explique, em três frases, por que o DNS inteligente da CDN faz o usuário de Lisboa falar com o PoP de Paris e não com o servidor no Brasil. *Resposta esperada:* quando o navegador pergunta o endereço do site, a consulta chega ao DNS inteligente da CDN. Esse DNS identifica a localização do usuário pelo IP e devolve o IP do PoP mais próximo (Paris), em vez do IP da origem. O navegador então se conecta a esse PoP, que responde do cache (hit) e só vai ao Brasil se não tiver a cópia (miss).

Limpeza (ao terminar o laboratório e os exercícios):

docker compose down -v
cd ..

Laboratório

1. Quem é quem.

docker compose exec primary psql -U postgres -c "SELECT pg_is_in_recovery();"
docker compose exec replica psql -U postgres -c "SELECT pg_is_in_recovery();"

Esperado: f no primary e t na réplica (a réplica está em modo de recuperação, ou seja, seguindo o primary).

2. A replicação está viva (e é assíncrona).

docker compose exec primary psql -U postgres -c "SELECT client_addr, state, sync_state FROM pg_stat_replication;"

Esperado:

 client_addr |   state   | sync_state
-------------+-----------+------------
 172.x.x.x   | streaming | async

3. Escreva no primary, leia na réplica.

docker compose exec primary psql -U postgres -c "CREATE TABLE produtos (id int primary key, nome text); INSERT INTO produtos VALUES (1,'Camiseta'),(2,'Caneca');"
sleep 1
docker compose exec replica psql -U postgres -c "SELECT * FROM produtos;"

Esperado: as duas linhas aparecem na réplica.

4. A réplica não aceita escrita.

docker compose exec replica psql -U postgres -c "INSERT INTO produtos VALUES (9,'Intruso');"

Esperado: ERROR: cannot execute INSERT in a read-only transaction. É por isso que a aplicação precisa do write splitting.

5. Consistência eventual, ao vivo. Pause a aplicação das mudanças na réplica, escreva no primary e compare:

docker compose exec replica psql -U postgres -c "SELECT pg_wal_replay_pause();"
docker compose exec primary psql -U postgres -c "INSERT INTO produtos VALUES (3,'Boné');"
echo "primary:"; docker compose exec primary psql -U postgres -tA -c "SELECT count(*) FROM produtos;"
echo "réplica:"; docker compose exec replica psql -U postgres -tA -c "SELECT count(*) FROM produtos;"

Esperado: 3 no primary e 2 na réplica. Agora retome:

docker compose exec replica psql -U postgres -c "SELECT pg_wal_replay_resume();"
sleep 1
docker compose exec replica psql -U postgres -tA -c "SELECT count(*) FROM produtos;"

Esperado: 3. Por um tempo, dois nós responderam coisas diferentes e depois convergiram: consistência eventual.

6. Cache-aside com Redis, lendo da réplica. Use o cache-aside.sh do segundo exemplo comentado:

bash cache-aside.sh 1
bash cache-aside.sh 1
bash cache-aside.sh 1
docker compose exec redis redis-cli TTL produto:1

Esperado: MISS Camiseta, depois HIT Camiseta duas vezes, e um (integer) entre 1 e 30 (os segundos restantes de vida da chave).

7. O preço do cache: dado velho. A chave do cache vive só 30 s, então rode este passo logo depois do passo 6. Se passou mais que isso, rode bash cache-aside.sh 1 antes do UPDATE para repovoar o cache; caso contrário o dado velho não aparece (você veria MISS Camiseta Azul direto). Altere o dado e releia:

docker compose exec primary psql -U postgres -c "UPDATE produtos SET nome='Camiseta Azul' WHERE id=1;"
bash cache-aside.sh 1

Esperado: HIT Camiseta. O cache serve o valor antigo até expirar. Invalide ao escrever:

docker compose exec redis redis-cli DEL produto:1
sleep 1   # dá tempo para a réplica receber o UPDATE (a replicação é assíncrona)
bash cache-aside.sh 1

Esperado: MISS Camiseta Azul. Se aparecer MISS Camiseta, a leitura chegou à réplica antes da mudança: é o atraso de replicação da consistência eventual. Repita o DEL e a leitura. Quem escreve precisa invalidar o cache (ou aceitar o TTL como janela de defasagem).

Exercícios

Faça os exercícios na ordem: o 2 e o 3 alteram o estado do laboratório.

1. Sharding por hash, e o custo do re-sharding. Distribua 10 IDs em 2 shards pelo módulo (um hash bem simples) e, depois, veja quantos IDs trocam de shard ao passar para 3 shards:

   for id in $(seq 1 10); do echo "usuario $id -> shard $((id % 2))"; done
    
   mudou=0
   for id in $(seq 1 1000); do
     # compara o shard antigo (2 shards) com o novo (3 shards)
     if [ $((id % 2)) -ne $((id % 3)) ]; then mudou=$((mudou + 1)); fi
   done
   echo "IDs que trocaram de shard: $mudou de 1000"

   Esperado: IDs que trocaram de shard: 667 de 1000. Cerca de dois terços dos dados precisariam migrar: é a dor do re-sharding. Bancos como Cassandra e DynamoDB fazem esse trabalho de forma transparente. Pergunta: e o sharding por range, que problema ele tem? *Resposta esperada:* hotspots. Como cada shard recebe uma faixa fixa de valores, se os dados ou os acessos não se distribuem por igual entre as faixas, um shard fica sobrecarregado enquanto os outros ficam ociosos. Dois exemplos: na divisão A a M e N a Z, nomes concentrados em certas letras pesam mais num dos lados; numa divisão por faixa de ID crescente (ou de data), todas as escritas novas caem no último shard. Em troca, o range facilita consultas por faixa, que é justamente o que o hash dificulta.
2. Partição de rede (CAP na prática). Desconecte a réplica da rede, escreva no primary e leia dos dois lados:

   docker network disconnect lab-etapa-05_default $(docker compose ps -q replica)
   docker compose exec primary psql -U postgres -c "INSERT INTO produtos VALUES (4,'Chaveiro');"
   docker compose exec primary psql -U postgres -tA -c "SELECT count(*) FROM produtos;"
   docker compose exec replica psql -U postgres -tA -c "SELECT count(*) FROM produtos;"

   Esperado: o primary com uma linha a mais que a réplica. A réplica respondeu (disponibilidade) com dado desatualizado (sem consistência). Reconecte com docker network connect lab-etapa-05_default $(docker compose ps -q replica) e espere até cerca de 1 minuto: a conexão de replicação antiga pode ficar pendurada até o wal_receiver_timeout estourar (60 s por padrão), e a réplica pode voltar com outro IP. Para acompanhar, rode docker compose exec replica psql -U postgres -c "SELECT status FROM pg_stat_wal_receiver;"; quando a replicação volta, o status é streaming. Rode o count(*) de novo e confira que os números convergem. Pergunta: se a sua prioridade fosse consistência, o que a réplica deveria ter feito durante a partição? *Resposta esperada:* escolhendo consistência (CP), a réplica deveria recusar a leitura, devolvendo erro ou saindo de rotação, enquanto não pudesse confirmar que está em dia com o primary; o preço é a disponibilidade durante a partição. O laboratório mostrou o outro lado, a escolha por disponibilidade (AP): a réplica respondeu com o que tinha, e os nós convergiram depois (consistência eventual).
3. Failover manual e o RTO. Derrube o primary e promova a réplica:

   docker compose stop primary
   time docker compose exec replica psql -U postgres -c "SELECT pg_promote();"
   docker compose exec replica psql -U postgres -c "SELECT pg_is_in_recovery();"
   docker compose exec replica psql -U postgres -c "INSERT INTO produtos VALUES (5,'Adesivo');"

   Esperado: pg_promote devolve t, pg_is_in_recovery passa a f e o INSERT funciona. Você acaba de fazer um failover. Perguntas: que parte do RTO foi automática, e qual dependeu de você? Com replicação assíncrona, o que pode ter ficado para trás no momento da queda (qual RPO você aceitou)? Para recomeçar o laboratório depois, rode docker compose down -v e suba tudo de novo. *Resposta esperada:* quase nada do RTO foi automático: perceber a queda, decidir promover e rodar o pg_promote dependeram de você (um serviço gerenciado como o RDS automatiza a detecção e a promoção). Quanto ao RPO, com replicação assíncrona as transações já confirmadas no primary que ainda não tinham chegado à réplica no instante da queda se perdem; com rede local costuma ser pouco ou nada, mas não há garantia, e é essa janela que o RPO mede.
4. RPO e RTO. O negócio define RPO de 5 minutos e RTO de 15. Replicação síncrona ou assíncrona? O failover pode ser manual? Justifique. *Resposta esperada:* a replicação assíncrona basta, porque o negócio aceita perder até 5 minutos de transações, desde que o atraso da réplica seja monitorado e fique dentro desse limite; a síncrona só seria necessária se o RPO fosse próximo de zero. O failover pode ser manual se a equipe conseguir detectar, decidir e promover com folga dentro dos 15 minutos (com plantão e um roteiro testado); automatizá-lo reduz o risco de estourar o RTO e de erro humano, ao custo de mais complexidade.

Limpeza (ao terminar o laboratório e os exercícios):

docker compose down -v
cd ..

Laboratório

1. Sobe e verifica.

docker compose up -d --build
sleep 3
bash verificar.sh

Esperado:

OK     asset servido pela borda (HIT)
OK     requisições distribuídas em 3 réplicas
OK     carrinho visível em qualquer réplica
OK     pedido aceito de forma assíncrona (202)

2. Resiliência: derrube uma réplica.

docker stop $(docker compose ps -q app | head -n 1)
for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code}\n" "localhost:8080/"; done | sort | uniq -c

Esperado: 20 200. Suba de volta e atualize o Nginx, que resolve nomes só na partida (a réplica pode voltar com outro IP):

docker compose up -d
docker compose exec lb nginx -s reload

3. Antes e depois, em números. Use a função de carga da Etapa 01 (redefina se abriu um terminal novo) contra a arquitetura e contra um "monolito" de uma instância só:

carga() { time (seq 1 100 | xargs -P 20 -I{} curl -s -o /dev/null "$1"); }
 
# Depois: borda, LB e 3 réplicas
carga http://localhost:8080/
 
# Antes: uma instância stateful, sem LB e sem borda
docker run -d --name monolito -p 8090:8080 -e MODO=memoria lab-app
carga http://localhost:8090/

Esperado: cerca de 1,7 s contra cerca de 5 s. Agora o ponto único de falha:

docker stop monolito
curl -s -o /dev/null -w "%{http_code}\n" --max-time 2 localhost:8090/

Esperado: 000. Remova com docker rm monolito.

4. Observabilidade: os três pilares com o que temos.

*Métricas* (o quê):

docker stats --no-stream

Esperado: uma tabela com CPU e memória de cada container (NAME, CPU %, MEM USAGE / LIMIT...).

*Logs* (por quê). A aplicação registra cada requisição:

curl -s "localhost:8080/carrinho?user=ana" > /dev/null
docker compose logs --no-color app | tail -n 3

Esperado: linhas como app-2 | [9f8e7d6c5b4a] GET /carrinho?user=ana rid=4c1d....

*Traces* (onde). Siga um ID de requisição pelas camadas:

RID=$(docker compose logs --no-color lb | grep carrinho | tail -n 1 | grep -o 'rid=[a-f0-9]*')
[ -n "$RID" ] || echo "nenhum rid encontrado: rode antes o curl do carrinho do passo anterior"
echo "seguindo $RID"
docker compose logs --no-color lb app | grep "$RID"

Esperado: duas linhas com o mesmo rid, uma do lb (com upstream= mostrando qual réplica foi escolhida) e outra do app (a réplica que atendeu). É um mini trace distribuído: o mesmo identificador costurando o caminho da requisição por duas camadas. Ferramentas reais de tracing fazem isso de forma automática e medem o tempo de cada trecho.

Exercícios

1. Diagnóstico. O e-commerce abaixo caiu na Black Friday. Liste os pontos de falha e, para cada um, a peça do guia que o resolve e em que etapa ela foi estudada: - aplicação e banco no mesmo servidor; - carrinho em variável de sessão; - imagens e JavaScript servidos pela própria aplicação; - e-mail de confirmação enviado antes de responder ao cliente; - um único servidor na frente de tudo. *Resposta esperada:* aplicação e banco no mesmo servidor: separar os dois, com a aplicação em instâncias próprias e o banco em serviço gerenciado com read replicas (Etapas 01, 03 e 05); carrinho em variável de sessão: aplicação stateless, com o estado no Redis ou no banco (Etapa 03); imagens e JavaScript servidos pela aplicação: CDN na frente (Etapa 04); e-mail antes de responder: fila e workers, com o produtor respondendo na hora (Etapa 03); servidor único na frente: load balancer com uma frota de instâncias (Etapas 01 e 02).
2. Monolito ou microsserviços? Uma startup com 6 pessoas, um único time, quer "ser como o Nubank". Use a Lei de Conway e a tabela de custos para argumentar a favor de um monolito escalável (stateless, em ASG) como ponto de partida. *Resposta esperada:* pela Lei de Conway, um time único e centralizado tende a produzir (e a operar bem) um monolito; microsserviços refletem times pequenos e autônomos, que a startup ainda não tem. A tabela mostra o preço dos microsserviços: complexidade operacional massiva, latência e novos pontos de falha na rede, depuração distribuída difícil. Um monolito stateless em ASG escala horizontalmente com simplicidade de desenvolvimento, teste, deploy e depuração, e pode ser dividido mais tarde, quando surgirem times e gargalos que justifiquem.
3. Gargalo ou pilar? Você vê a latência do /carrinho triplicar. Qual pilar você consulta primeiro para saber *que* algo mudou, qual para saber *por quê* e qual para saber *onde* o tempo foi gasto? *Resposta esperada:* métricas para saber que algo mudou (e disparar o alerta), logs para saber por quê e traces para saber onde o tempo foi gasto, ao longo dos serviços por onde a requisição passou.
4. Orçamento de erro (conta). Um SLO de 99,9% de disponibilidade em 30 dias deixa quantos minutos de indisponibilidade de orçamento? (Dica: 30 dias têm 43.200 minutos.) *Resposta esperada:* 0,1% de 43.200 = 43,2 minutos.
5. Plano de upgrade. Escreva o que você adicionaria ao docker-compose.yml para incluir o banco primary e a réplica da Etapa 05 atrás da API, e como a aplicação faria o write splitting. *Resposta esperada:* acrescentar ao compose os serviços primary e replica (com o init-primary.sh, o replica.sh e o healthcheck da Etapa 05) e passar à app os endereços dos dois por variáveis de ambiente. No write splitting, os comandos de escrita (INSERT, UPDATE, DELETE) vão para o primary e as leituras (SELECT) para a replica, de preferência com o cache-aside do Redis na frente. A aplicação de teste não fala com Postgres, então seria preciso acrescentar a ela um cliente de Postgres.

Limpeza:

docker compose down -v
docker rm -f monolito 2>/dev/null
cd ..