📌 Material de chegada: 1 fator OK + 1 fator a melhorar + 1 chamada externa mapeada com cenário de falha. Esses itens alimentam o daily de abertura.
As ideias que fazem um serviço não cair: 12-factor, idempotência, circuit breaker, containers, API gateway e configs seguras.
Cada grupo escolhe 2 padrões, descreve onde aplica no projeto e atualiza o diagrama. No fim: checkpoint com demo das APIs.
docs/🎯 Saída do dia: arquivo docs/cloud-practices.md + diagrama atualizado via Merge Request, e uma demo funcionando da API do grupo. Não vale ponderada — vale prática boa que ajuda na entrega final.
🧠 Em 1 frase: um app bem feito não depende de mágica do ambiente — ele lê config de fora, não guarda estado na memória, e qualquer cópia dele faz a mesma coisa. Assim você pode rodar 1 ou 50 cópias sem medo.
Se a API segue essas 4 ideias, ela roda igual na sua máquina e na nuvem — e pode ter várias cópias atendendo ao mesmo tempo sem bagunçar os dados.
Senha escrita dentro do código · "só funciona na minha máquina" · o app salva arquivo no próprio disco e some quando reinicia.
O app manda POST /pagamento, o servidor processa, mas a resposta se perde no caminho. O app acha que falhou e tenta de novo. Resultado: 2 cobranças.
Lição: não dá pra confiar em "mandei só uma vez". Toda gravação importante precisa ser idempotente.
O app gera um código único e manda junto. O servidor guarda (código → resposta). Se vier de novo o mesmo código, ele devolve a resposta antiga sem reprocessar.
Ideia-chave: "repetir o mesmo pedido dá o mesmo resultado" — não soma, não duplica.
🔌 Analogia do disjuntor: assim como o disjuntor da casa "desarma" quando há curto pra não queimar tudo, o circuit breaker para de chamar um serviço que está caindo — e tenta religar sozinho depois.
Toda chamada tem um limite de espera. Sem isso, 1 serviço lento trava sua tela inteira.
Falhou? Tenta de novo, esperando um pouco mais a cada vez. Só funciona com idempotência (slide anterior).
Para de bater num serviço que já está caído. Devolve erro rápido em vez de travar esperando.
Separe os recursos por dependência. Um problema num serviço não afunda os outros (como os compartimentos de um navio).
Como cada cópia é igual (lembra do stateless?), a nuvem pode subir 2, 5 ou 20 cópias conforme o número de usuários cresce — e baixar quando esvazia.
Um "porteiro" (load balancer) divide os pedidos entre as cópias.
💡 Na prática: docker build cria a caixa, docker run liga ela. A mesma caixa que roda na sua máquina é a que vai pra nuvem — zero surpresa.
O app precisa saber o endereço de cada serviço, cuidar de login em cada um, e tratar limites de uso em cada um. Vira bagunça quando o sistema cresce.
Cada serviço exposto = mais portas abertas = mais risco.
O app fala só com uma porta. O gateway confere o login, controla o uso e encaminha pro serviço certo lá de trás.
Os serviços internos ficam escondidos e protegidos.
Confere o token uma vez, na entrada.
Ex.: 100 pedidos/min por usuário.
/usuarios → serviço de usuários.
Cuida da criptografia da conexão.
Exemplos reais: AWS API Gateway, Azure API Management, Kong, NGINX. (No projeto, mesmo um backend único já pode centralizar isso.)
.env com senha enviado pro GitPor quê: qualquer um com acesso ao repo vê tudo — e o histórico do Git guarda pra sempre.
.env fica só na sua máquina (e no .gitignore!)Cofres: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager.
✔️ Checklist rápido do projeto: o .env está no .gitignore? Tem algum .env ou senha já no histórico do Git? Se sim, troque a senha — ela já vazou.
Para cada um, em 2 ou 3 frases: o que é (com suas palavras) · onde no projeto faz sentido aplicar.
Pegar o diagrama de arquitetura da aula 3 e marcar onde cada um dos 2 padrões entra (gateway, container, config...).
Para cada padrão, qual requisito não funcional ele melhora? Ex.: Circuit Breaker → disponibilidade. Container → portabilidade.
📋 Entrega: arquivo docs/cloud-practices.md + diagrama atualizado, abertos via Merge Request no repositório do grupo.
⭐ Excelência: deixar 1 padrão funcionando de verdade no código — ex.: um timeout ou retry numa chamada externa da API.
🧠 6 padrões disponíveis: 12-Factor · Idempotência · Circuit Breaker · Containers · API Gateway · Configs seguras. Escolher 2.
docs/cloud-practices.md