Fecha o Bloco B da trilha. Foco: você consegue avaliar se "alta disponibilidade" que cliente promete (ou exige) é justificada ou exagero, e propõe arquitetura defensável sem cair em over-engineering.
Pré-requisito: Semana 4 (Cloud). Tempo estimado: 3-4 horas de leitura + 1 hora de exercício. Output prático: você responde "qual o SLA que o Team Studio garante?" com número fundamentado, não chute.
Por que essa semana importa
Escalabilidade e disponibilidade são onde clientes corporativos mais ASSUSTAM com promessas exageradas e onde fornecedores mais EXAGERAM pra fechar contrato. Quando cliente pergunta:
"Vocês garantem 99.99% de uptime? E quando o pico de Black Friday triplicar nossa demanda, vão escalar sozinho?"
Sua resposta define se você vira parceiro técnico sério ou vendedor de IA genérico. Sem fundamento, você promete e quebra. Com fundamento, você negocia números reais e cobra preço compatível.
Bônus: maioria das empresas EXIGE alta disponibilidade que não precisa. Saber identificar isso te diferencia (e te poupa de propor solução cara desnecessariamente).
1. O modelo mental: escalabilidade não é uma coisa só
Escalabilidade tem 2 dimensões + 3 conceitos relacionados que vão aparecer juntos em reunião:
1.1 Vertical scaling (scale up)
Trocar máquina pequena por máquina grande. Mesma máquina, mais recurso (CPU, RAM, disco).
Exemplo: VM t3.medium (2 vCPU, 4GB RAM) → c5.4xlarge (16 vCPU, 32GB RAM).
Vantagens: - Simples: nenhuma mudança de arquitetura - Bom pra bancos (escalar Postgres horizontalmente é doloroso) - Latência mais baixa (tudo numa máquina só)
Limitações: - Tem teto físico (maior VM hoje tem ~200 vCPU) - Caro: dobrar capacidade não dobra preço, geralmente é 3-4x - Downtime na troca (precisa parar pra trocar instância)
1.2 Horizontal scaling (scale out)
Ter VÁRIAS máquinas iguais, distribuindo carga entre elas.
Exemplo: 1 servidor web → 10 servidores idênticos atrás de load balancer.
Vantagens: - Sem teto teórico (você adiciona quantos quiser) - Custo linear (10x capacidade = 10x preço, mais ou menos) - Tolerância a falha: se 1 cair, outros 9 atendem - Pode desligar quando não precisa (auto-scaling)
Limitações: - Exige aplicação preparada (stateless, idempotente, etc) - Complexidade: precisa load balancer, service discovery, observability - Bancos são MUITO mais difíceis de escalar horizontalmente
1.3 Quando escolher cada uma
Regra prática: - Banco de dados primário: vertical primeiro, horizontal só quando não der mais - Aplicação web/API: horizontal desde o início (mesmo que comece com 1 instância) - Cache (Redis): ambos, depende do tamanho - Workers de processamento: horizontal sempre
Pergunta de reunião:
"Vocês escalam horizontalmente ou verticalmente? Onde é o gargalo principal - banco, app, ou cache?"
Resposta revela arquitetura toda. Se cliente diz "verticalmente, porque não conseguimos rodar 2 instâncias do app", ele tem app stateful que precisa ser refatorado.
2. Autoscaling em prática
Autoscaling é a capacidade de mudar quantidade de máquinas AUTOMATICAMENTE conforme demanda. Aparece em quase toda discussão de infra moderna.
2.1 Os componentes
- Auto Scaling Group (ou equivalente): define mínimo, máximo e desejado de instâncias
- Métricas de gatilho: CPU, memória, latência, requests por segundo, tamanho de fila
- Políticas de scaling: regras tipo "se CPU > 70% por 5 min, adiciona 2 instâncias"
- Health checks: verifica se instância nova tá pronta antes de mandar tráfego
2.2 Estratégias comuns
Target tracking: você define meta (ex: "manter CPU média em 50%"), provedor ajusta quantidade automaticamente.
Step scaling: regras explícitas. CPU > 70%, +2 instâncias. CPU < 30%, -1 instância.
Scheduled scaling: aumenta capacidade em horário fixo (Black Friday começa 8h, adiciona 20 instâncias às 7h).
Predictive scaling (avançado, AWS): ML aprende padrão de tráfego e antecipa picos.
2.3 Limites e armadilhas
Cold start: instância nova demora pra subir. Quando autoscaling dispara, pode levar 1-5 min pra ter capacidade extra. Pra picos rápidos, isso falha.
Solução: manter "buffer" (mínimo maior que necessário no estável), warm pool (instâncias pré-prontas em standby), ou usar serverless (escala em milissegundos).
Database connections: cada instância nova abre conexões no banco. Banco aguenta? Você tem connection pool?
Cost runaway: configuração ruim de autoscaling pode disparar 100 instâncias e gerar fatura de 10x num dia. Tem TETO definido.
Pergunta de reunião:
"Como vocês balanceiam autoscaling vs custo previsível? Tem teto máximo configurado? Já tiveram cost runaway?"
3. Load balancers: distribuindo o tráfego
Load balancer (LB) recebe requisições do mundo externo e distribui entre múltiplas máquinas. Sem LB, você não consegue escalar horizontalmente.
3.1 L4 vs L7 - em qual camada do TCP/IP
L4 (Layer 4 - transport): balanceia baseado em IP/porta. Rápido, não entende conteúdo da mensagem.
- AWS NLB (Network Load Balancer)
- Bom pra: TCP genérico, gRPC, WebSocket
- Limitação: não consegue rotear baseado em URL ou header
L7 (Layer 7 - application): balanceia entendendo HTTP/HTTPS. Pode rotear por URL, header, cookie.
- AWS ALB (Application Load Balancer), GCP Load Balancer, nginx, Caddy (faz isso!)
- Bom pra: APIs REST, sites web, microserviços com paths diferentes
- Mais caro que L4 e ligeiramente mais lento
3.2 Algoritmos de balanceamento
- Round-robin: alterna entre máquinas em sequência. Simples mas burro.
- Least connections: manda pra máquina com menos conexões abertas. Mais inteligente.
- IP hash: usuário com IP X sempre vai pra mesma máquina. Útil pra session affinity.
- Weighted: máquinas diferentes recebem proporção diferente. Útil pra canário (5% pro v2, 95% pro v1).
3.3 Health checks
LB checa periodicamente se cada máquina tá saudável (geralmente HTTP GET em endpoint /health ou /healthz).
- Status 200: máquina recebe tráfego
- Status não-200 ou timeout: LB tira do pool até voltar a estar saudável
Importante: o /healthz da sua aplicação tem que checar dependências (banco, cache, APIs externas) e responder rapidamente. Se ele só retorna "OK" sem checar nada, é falso positivo.
Pergunta de reunião:
"O que o endpoint de health check da aplicação verifica? Só responde 200 ou checa dependências?"
Resposta vaga = problema de observability.
3.4 Sticky sessions / Session affinity
Garantir que usuário X sempre cai na mesma máquina (porque máquina guarda sessão em memória local).
Quando precisa: aplicação stateful. Bandeira amarela - você tem trabalho de refatorar pra stateless.
Quando NÃO usar: SPAs modernas, JWT, sessões em Redis/banco. Stateless é melhor sempre que dá.
4. CDN avançado: o que cacheia e o que não cacheia
Vimos CDN na Semana 4 superficialmente. Pra escalabilidade séria, precisa entender em detalhe.
4.1 O que CDN cacheia bem
- Arquivos estáticos (JS, CSS, imagens, PDFs, vídeos)
- Páginas HTML que não mudam por usuário
- Respostas de API que são iguais pra todo mundo
- Conteúdo "público"
4.2 O que CDN cacheia mal ou não cacheia
- Páginas personalizadas (dashboard do usuário)
- Respostas que mudam por header de autenticação
- POSTs (CDN cacheia GETs basicamente)
- Conteúdo dinâmico em tempo real
4.3 Invalidação - o calo de todo mundo
Quando arquivo muda, CDN ainda serve versão antiga até expirar. Pra forçar atualização:
- Time-based: TTL baixo (5 min, 1h, 1 dia). Trade-off entre frescor e taxa de hit.
- Hash no nome:
/assets/app.a3f4b9.jsmuda hash a cada deploy. Browser pega versão nova automaticamente. - Purge / Invalidação: comando manual pra dizer "invalide essa URL". Pode demorar minutos pra propagar.
4.4 Stale-while-revalidate (técnica moderna)
Serve cache velho IMEDIATAMENTE enquanto busca versão nova em background. Usuário sempre vê algo rápido, mesmo que ligeiramente desatualizado.
Header HTTP:
Cache-Control: max-age=60, stale-while-revalidate=600
Significa: válido por 60s. Depois disso até 600s, serve velho enquanto busca novo. Após 600s, espera novo.
Pergunta de reunião:
"Qual estratégia de cache do CDN de vocês? Stale-while-revalidate ou TTL puro? Como invalidam após deploy?"
4.5 Edge computing - código no CDN
Provedores modernos (Cloudflare Workers, Vercel Edge Functions, AWS Lambda@Edge) deixam você RODAR código nos pontos da CDN.
Uso típico: autenticação, redirect baseado em geolocalização, A/B testing, personalização leve.
Vantagem: latência absurdamente baixa (50-100ms vs 200-500ms indo até origem). Limitação: tempo de execução curto (50-200ms), sem state, cold start (ainda existe).
5. Multi-region: quando vale, complexidade que traz
Rodar em mais de uma região aumenta disponibilidade e reduz latência pra usuários distantes, mas é CARO e COMPLEXO.
5.1 Tipos de multi-region
Active-Passive (Hot Standby): região A serve tráfego, região B está pronta mas inativa. Se A cair, B assume.
- Vantagem: menos complexo (só uma região serve por vez)
- Desvantagem: capacidade de B é desperdiçada em horário normal
Active-Active: duas regiões servem tráfego simultaneamente, balanceadas via DNS ou anycast.
- Vantagem: usa toda capacidade, latência menor pra usuários globais
- Desvantagem: complexidade alta (precisa sincronizar dados, conflitos)
Active-Active com região mestre: escritas vão pra região A, leituras podem vir de A ou B.
- Compromisso: simplicidade de escrita única + latência baixa de leitura
5.2 O problema do banco em multi-region
Aplicações são fáceis de replicar entre regiões. Bancos são MUITO mais complicados.
Opções pra banco: 1. Read replicas em outras regiões: leituras locais, escritas vão pra região primária. Bom pra cargas read-heavy. 2. Multi-master: escritas em qualquer região, sincronização eventual. Conflitos podem acontecer. 3. Banco global gerenciado: DynamoDB Global Tables, Aurora Global Database, Cloud Spanner. Caro, mas resolve.
5.3 Custo real
Multi-region custa 2-3x mais que single-region pelo mesmo nível de capacidade. Tem que justificar.
Quando vale: - Receita > US$ 10M/ano e downtime custa muito - Usuários globalmente distribuídos (Europa + Brasil + Asia precisa de regiões locais) - Requisitos regulatórios (dados europeus na Europa, brasileiros no Brasil)
Quando NÃO vale: - Startup com poucos usuários - Mercado regional (só Brasil) - Custo de complexidade > custo de downtime aceitável
6. SLA dos provedores cloud - números reais
Quando provider promete uptime, ele te dá um percentual. Mas isso significa quanto downtime aceitável?
6.1 Tabela de downtime por SLA
| SLA | Downtime/ano | Downtime/mês | Downtime/dia |
|---|---|---|---|
| 99% | 3.65 dias | 7.31 horas | 14.4 min |
| 99.9% | 8.77 horas | 43.83 min | 1.44 min |
| 99.95% | 4.38 horas | 21.92 min | 43.2 s |
| 99.99% | 52.6 min | 4.38 min | 8.64 s |
| 99.999% | 5.26 min | 26.3 s | 864 ms |
Observações importantes: - "Cinco noves" (99.999%) é considerado nível enterprise. Pouca empresa atinge de verdade. - Maioria das empresas comerciais opera entre 99.5% e 99.9% efetivamente. - Promessas de 99.99% pra cima geralmente são teóricas (cláusula de contrato), não realidade observada.
6.2 SLA composto
Se seu sistema usa 5 serviços, cada um com SLA 99.9%, qual é seu SLA real?
0.999 ^ 5 = 0.995 = 99.5%
Não é 99.9%, é 99.5%. Cada dependência reduz disponibilidade composta.
Implicação: prometer 99.9% pro cliente sendo que você usa 5 SaaS de 99.9% cada significa quebrar SLA. Você precisa de redundância OU SLA composto realista.
6.3 O que provedor REALMENTE garante
Cloud SLA tem letrinha miúda. Por exemplo, AWS EC2:
- Promessa: 99.99% (multi-AZ)
- Mas só vale se: você rodou em 2+ AZs E elas caíram juntas
- Penalidade: crédito de 10-30% da fatura do mês
Crédito não cobre perda de receita do cliente.
Pergunta de reunião:
"Qual o SLA garantido contratualmente pelo cloud provider de vocês? Tem penalidade real ou só crédito simbólico? Qual o histórico real de downtime?"
6.4 Disponibilidade observada vs prometida
Empresa madura mede disponibilidade REAL, não confia só no SLA do provedor. Ferramentas:
- Status pages próprias: comunica downtime publicamente
- External monitoring: serviços tipo Pingdom, UptimeRobot, Datadog Synthetic checam de fora
- Error budget: tolerância restante antes de quebrar SLO mensal
7. Disaster recovery (DR) e high availability (HA)
7.1 HA - não cair (ou cair pouco)
Estratégias técnicas pra sistema continuar funcionando quando componentes falham:
- Múltiplas AZs/regiões
- Redundância de instâncias
- Failover automático
- Auto-healing
- Backups regulares (cinto de segurança)
Métrica chave: uptime real / uptime prometido.
7.2 DR - voltar rápido depois de catástrofe
Plano pra restaurar operação após desastre grave (incêndio, ataque, perda de região inteira).
Métricas chave: - RPO (Recovery Point Objective): quanto dado você aceita perder. RPO 0 = não pode perder nada (replicação síncrona). RPO 24h = aceita perder 1 dia (backup diário). - RTO (Recovery Time Objective): quanto tempo pra voltar. RTO 0 = nunca cair (impossível). RTO 4h = 4 horas pra estar de pé.
7.3 Estratégias por nível de criticidade
Backup só (RTO horas/dias, RPO horas/dias): - Backup diário em outra região - Restaurar manualmente - Mais barato, mais demorado
Pilot light (RTO 10-60 min, RPO minutos): - Infraestrutura mínima rodando em região B - Banco replicado continuamente - Aplicação escala sob demanda quando A cai
Warm standby (RTO < 10 min, RPO segundos): - Capacidade reduzida (50%) rodando em B - Quase pronta pra assumir - Escala quando A cai
Multi-site Active-Active (RTO 0, RPO 0): - Duas regiões ativas simultaneamente - Mais cara, mais complexa - Pra negócios críticos (banco, e-commerce de alto volume)
Pergunta de reunião:
"Qual estratégia de DR de vocês? Pilot light, warm standby ou active-active? Quando foi a última vez que testaram o DR?"
Empresa que NÃO testa DR provavelmente vai descobrir que não funciona na hora errada.
8. Cinco perguntas que destravam reunião de escalabilidade/HA
8.1 "Qual o pico atual de tráfego/uso? Quantos usuários simultâneos? Quantos requests/segundo?"
Por que importa: capacidade real, não capacidade teórica. Se cliente não sabe, é red flag.
8.2 "Vocês usam autoscaling? Quais métricas disparam? Qual o teto configurado?"
Por que importa: revela maturidade. Sem autoscaling = vulnerável a picos. Com teto certo = cliente cuidadoso.
8.3 "Qual SLA garantem? E qual o número real observado nos últimos 12 meses?"
Por que importa: separa promessa de realidade.
8.4 "RPO e RTO de vocês? Quando rodaram último DR drill?"
Por que importa: empresa madura testa DR regularmente. Empresa que não testa = não tem DR de verdade.
8.5 "Como vocês detectam degradação antes do cliente reclamar? Status page externa, alertas, etc?"
Por que importa: revela cultura de observability. Cliente que descobre tudo via reclamação = oportunidade pra Team Studio.
9. Exercício prático
Cenário: cliente Team Studio em discovery. E-commerce que vende eletrônicos, R$ 100M/ano, 80% das vendas em 2 datas (Black Friday + Natal). Diz:
"Em 2023, na Black Friday, nosso site ficou fora do ar por 4 horas das 10 da manhã ao meio-dia. Perdemos R$ 800k em vendas. Em 2024, contratamos serviço cloud com 'auto-scaling' mas continuou caindo. Em 2025, queremos garantir 99.99% durante a Black Friday. Conseguem entregar isso?"
Pratique: 1. Liste 5 perguntas técnicas antes de prometer qualquer coisa 2. Identifique 3 razões plausíveis pra "auto-scaling" ter falhado em 2024 3. Avalie se a meta de 99.99% durante Black Friday é realista E qual a estratégia técnica + custo aproximado 4. Identifique 1 oportunidade pra Team Studio dentro desse cenário
(Sugestões no fim.)
10. Material extra
Leitura essencial: - "Site Reliability Engineering" (Google) - capítulos 3-5 (SLOs, error budgets) são leitura obrigatória pra entender SLA moderno - AWS Well-Architected Framework, pilar Reliability - Blog do AWS post-mortems (https://aws.amazon.com/message/) - leitura de DR real
Calculadoras práticas: - https://uptime.is/ (calcula downtime aceitável por SLA) - https://calculator.aws/ (custo de multi-AZ vs multi-region)
Hands-on: - Crie alarme no AWS CloudWatch que dispara auto-scaling baseado em CPU - Configure um load balancer com 2 instâncias EC2 (Free Tier serve) - Simule queda de uma instância e observe load balancer redirecionando
11. Sugestões pro exercício prático (veja só depois de tentar)
5 perguntas técnicas:
- "Quanto tráfego o site recebe num dia normal vs no pico da Black Friday? Estimativa em RPS (requests por segundo) ou usuários simultâneos."
- "Qual a arquitetura atual? Onde está o gargalo principal (app, banco, cache, CDN)? Como sabem disso?"
- "O 'auto-scaling' de 2024: era target tracking, step ou scheduled? Quais métricas disparavam? Qual o teto configurado?"
- "Quando começa o pico real do Black Friday? Vocês fazem load test antes simulando esse volume?"
- "Banco aguenta o pico ou ele é o gargalo? Têm read replicas?"
3 razões plausíveis pra auto-scaling ter falhado:
- Cold start: provider levou 5+ min pra subir instâncias novas, pico foi mais rápido que isso. Solução: warm pool ou serverless.
- Banco como gargalo: app escalava, banco não. Banco saturava em 50% do pico esperado. Solução: read replicas + cache agressivo.
- Teto baixo demais: configuraram máximo de 10 instâncias e precisaram de 30. Auto-scaling parou no teto.
Avaliação da meta 99.99% na Black Friday:
- 99.99% durante o evento = downtime máximo de 26 segundos no dia
- TECNICAMENTE possível com multi-region active-active + banco com replica + load tests rigorosos
- Custo: provavelmente 5-10x infra normal só pra esse dia (escalar antes, monitorar durante, escalar depois)
- Honest pitch: "garantir 99.99% custa X. 99.9% (downtime 1.4 min/mês) custa Y. Vamos rever a meta com base em ROI da perda."
Oportunidade pra Team Studio:
Agente "early warning Black Friday": monitora 50+ métricas durante o evento, identifica anomalias semanticamente ("conversão caiu 30% em SP nos últimos 10 min, abandono no checkout subiu"), notifica time de plantão no WhatsApp. Não substitui SRE, complementa. Setup: 2 semanas. Valor: pode prevenir 2-3 horas de downtime perdido em buscar causa. ROI altíssimo.
12. Próxima semana
Esta semana fecha o Bloco B (Cloud e Infra). O Bloco C (DevOps) começa em seguida:
- Semana 6: Docker, containers e Kubernetes - fundamentos de deploy moderno, k8s sem virar especialista, alternativas modernas (Fargate, Cloud Run, Fly.io)
- Semana 7: CI/CD, observability e deploys - pipeline do commit até produção, 3 pilares de observability, 4 golden signals, plano 3 meses pra deploy contínuo