Boas práticas

Este guia apresenta padrões, princípios e estratégias comprovados em milhares de implantações.

Princípios de design

1. Comece simples e evolua aos poucos

Não complique a arquitetura antecipadamente. Comece com o design mais simples que atenda aos requisitos atuais e evolua depois.

Bom: um banco, um servidor de aplicação e um balanceador. Ruim: microsserviços em 5 regiões com registro de eventos desde o primeiro dia.

2. Projete para falhas

Considere que os componentes falharão. Inclua redundância e degradação controlada.

Bom: banco Multi-AZ, réplicas de failover e disjuntores de circuito. Ruim: qualquer ponto único de falha.

3. Meça antes de otimizar

Não otimize sem dados. Use módulos de análise e monitoramento.

Bom: executar o analisador de escalabilidade para identificar gargalos reais. Ruim: “O banco provavelmente está lento; vamos adicionar cache”.

4. Entenda vantagens e desvantagens

Toda decisão envolve concessões. Documente-as.

Bom: “Escolhemos um monólito para lançar rápido e migraremos para microsserviços com 100k usuários”. Ruim: “Vamos usar microsserviços para escalar”, sem entender a complexidade envolvida.

5. Automatize tudo

Processos manuais não escalam. Automatize implantações, monitoramento e escalabilidade.

Bom: infraestrutura como código com Terraform, grupos de escalabilidade automática e pipelines CI/CD. Ruim: provisionamento manual e decisões manuais de capacidade.

Padrões comuns de arquitetura

Padrão: aplicação web monolítica

Quando usar: MVP, uma equipe e <100k usuários.

Topologia:

Users
  ↓
Load Balancer (ELB)
  ↓
App Servers (3+ instances, auto-scaled)
  ↓
Cache Layer (Redis)
  ↓
Database (Primary + Read Replicas)
  ↓
Object Storage (S3)

Vantagens:

• Desenvolvimento e depuração simples.
• Implantação e escala horizontal fáceis.
• Baixa sobrecarga operacional.

Desvantagens:

• Código extenso fica difícil de manter.
• O banco compartilhado limita a escala.
• Dependência de linguagem e framework.

Quando evoluir: ao atingir gargalos no banco com 50k+ usuários.

Padrão: arquitetura de microsserviços

Quando usar: equipes grandes, >100k usuários e vários serviços.

Topologia:

API Gateway
├─ Auth Service
├─ User Service
├─ Product Service
├─ Order Service
├─ Payment Service
├─ Notification Service
└─ Analytics Service

Shared Infrastructure:
- Service Mesh (Istio, Linkerd)
- Message Bus (Kafka, RabbitMQ)
- Distributed Tracing
- Centralized Logging

Vantagens:

• Escala independente por serviço.
• Autonomia das equipes.
• Flexibilidade tecnológica e múltiplas linguagens.
• Implantação individual dos serviços.

Desvantagens:

• Maior complexidade operacional.
• Desafios distribuídos: consistência eventual e depuração.
• Latência entre serviços.
• Exige práticas DevOps maduras.

Quando usar: quando o monólito for um gargalo E a organização da equipe permitir.

Padrão: sem servidor, FaaS

Quando usar: cargas orientadas a eventos, demanda variável e atenção a custos.

Topologia:

API Gateway
  ↓
Lambda Functions (auto-scaled to zero)
  ├─ DynamoDB (serverless database)
  ├─ S3 (object storage)
  ├─ SQS/SNS (messaging)
  └─ CloudWatch Logs

Vantagens:

• Pagamento apenas pelo tempo de computação utilizado.
• Redução automática a zero quando ocioso.
• Desenvolvimento e implantação simples.
• Sem gerenciamento de infraestrutura.

Desvantagens:

• Latência de inicialização a frio.
• Personalização limitada do ambiente.
• Dependência de AWS Lambda ou GCP Functions.
• Depuração mais difícil que em servidores tradicionais.

Quando usar: picos repentinos, cargas esporádicas e startups com poucos recursos operacionais.

Padrão: lago de dados e análise

Quando usar: grandes volumes, aprendizado de máquina e análise de dados.

Topologia:

Data Sources (streaming + batch)
  ↓
Data Ingestion (Kafka, Kinesis, SQS)
  ↓
Data Lake (S3, Blob Storage)
  ↓
ETL/Transform (Spark, Glue, Dataflow)
  ↓
Data Warehouse (Redshift, BigQuery, Snowflake)
  ↓
BI/ML Tools (Tableau, DataStudio, SageMaker)

Considerações:

• Qualidade e governança dos dados.
• Esquema definido na leitura ou na escrita.
• Tratamento de dados pessoais e privacidade.
• Otimização do desempenho de consultas.

Estratégias de otimização

Otimização de custos

1. Dimensionamento adequado

• Monitore o uso real, não a capacidade máxima.
• Use CloudWatch ou similar para identificar padrões.
• Reduza instâncias superdimensionadas.

2. Instâncias reservadas

• Preveja a carga estável.
• Compre reservas de 1-3 anos com desconto de 20-40%.
• Combine com escala automática para a carga variável.

3. Instâncias Spot

• Use em cargas tolerantes a falhas e não críticas.
• Custam 70% menos que as sob demanda.
• Considere interrupções de 2-5%.

4. Estratégia de cache

• Armazene dados frequentes em memória com Redis.
• Reduz a carga do banco em 50-80%.
• Use CDN para ativos estáticos: redução de custos de 80%+.

5. Transferência de dados

• Esse componente de custo elevado costuma ser ignorado.
• Use endpoints VPC para evitar cobranças de transferência.
• Comprima dados em trânsito.
• Use CloudFront para distribuição global.

Otimização de escalabilidade

1. Escala horizontal

• Adicione servidores atrás do balanceador.
• Banco: réplicas de leitura, primário e secundários.
• Cache: mais nós de cache.

2. Particionamento do banco

• Divida dados por usuário, região ou data.
• Cada partição escala independentemente.
• Concessão: complexidade de coordenação.

3. Pool de conexões

• Reutilize conexões do banco.
• Melhora a capacidade de processamento em 2-3x.
• Reduz a sobrecarga de conexão.

4. Estratégia de cache

• Armazene dados frequentes na aplicação.
• Guarde respostas da API com estratégia de invalidação.
• Use cache de consultas no ORM.

Boas práticas de segurança

1. Criptografia

• Em trânsito: TLS 1.3 em todos os endpoints.
• Em repouso: AES-256 com chaves KMS.
• Banco: volumes criptografados e proteção de dados pessoais na aplicação.

2. Autenticação e autorização

• MFA em todas as contas.
• OAuth 2.0 para integrações externas.
• Políticas IAM de privilégio mínimo.
• RBAC para usuários.

3. Segurança de rede

• Isolamento VPC e sub-redes privadas para bancos.
• Grupos de segurança com o mínimo de portas.
• NACLs como camada adicional.
• WAF no balanceador para proteger aplicações web.

4. Proteção de dados

• Tokenização e mascaramento de dados pessoais.
• Criptografia por campo para dados sensíveis.
• Políticas de retenção e exclusão de dados antigos.
• Backups com recuperação testada.

5. Monitoramento e auditoria

• CloudTrail ou registros de auditoria de todas as chamadas API.
• Alarmes CloudWatch para anomalias.
• Auditorias regulares.
• Manual de resposta a incidentes.

Boas práticas de desempenho

1. Latência

• CDN para ativos estáticos.
• Índices para consultas frequentes.
• Otimização de consultas, evitando N+1.
• Requisições de API em lote.

2. Capacidade de processamento

• Balanceamento entre servidores.
• Pool de conexões com o banco.
• Processamento assíncrono de tarefas longas.
• Escala vertical para cargas limitadas pela CPU.

3. Confiabilidade

• Verificações de integridade e recuperação automática.
• Disjuntores de circuito nas dependências.
• Novas tentativas com espera exponencial.
• Degradação controlada.

Boas práticas de implantação

1. Infraestrutura como código

• Tudo em Terraform ou CloudFormation.
• Controle de versão.
• Revisão por pares antes de aplicar.
• Testes prévios em homologação.

2. Implantação contínua

• Testes automatizados unitários, de integração e e2e.
• Implantação canário gradual.
• Implantação azul-verde sem indisponibilidade.
• Estratégia de reversão.

3. Monitoramento e observabilidade

• Logs estruturados em JSON.
• Rastreamento distribuído com X-Ray ou Jaeger.
• Métricas com Prometheus ou CloudWatch.
• Alertas de SLO, não apenas de erros.

Antipadrões: o que evitar

❌ Ponto único de falha, sem redundância. ❌ Engenharia excessiva, antes de o crescimento exigir complexidade. ❌ Ignorar custos, escolhendo recursos desnecessários. ❌ Escala manual, quando deveria ser automática. ❌ Sem monitoramento, operando sem visibilidade. ❌ Sem recuperação de desastres: esperança não é estratégia. ❌ Tudo em uma zona de disponibilidade, vulnerável à falha do centro de dados.

Próximos passos

• Explore os padrões → Biblioteca de padrões
• Aprenda análise de arquitetura → Módulos de análise
• Boas práticas de governança → Governança