 |
| Bellacosa Mainframe e os erros invisivei que destroem um projeto |
☕ Um Café no Bellacosa Mainframe
Os Erros Invisíveis que Destroem um Projeto Antes Mesmo da Primeira Linha de Código
"Arquitetura não é desenhar caixas e setas. É antecipar problemas que ainda não aconteceram."
Uma arquitetura pode parecer perfeita em um PowerPoint.
Microservices...
Docker...
Kubernetes...
Event Streaming...
Kafka...
REST...
GraphQL...
Cloud Native...
Tudo muito bonito.
Até o primeiro milhão de usuários.
Até o primeiro pico de Black Friday.
Até o primeiro deadlock.
Até a primeira perda de dados.
É nesse momento que aparecem os erros invisíveis.
1. Ignorar Consistência dos Dados
O erro
Muitos iniciantes acreditam que:
"Eventual Consistency resolve tudo."
Não resolve.
Consistência é uma decisão de negócio.
Não tecnológica.
Exemplo bancário
Imagine uma transferência.
Conta A
Saldo = 1000
↓
Transferir 900
↓
Conta B
Se um serviço atualizar a Conta A...
...e outro atualizar a Conta B alguns segundos depois...
Durante esses segundos:
Conta A = 100
Conta B = 0
O dinheiro "sumiu".
Ou pior...
Uma nova consulta pode permitir outra transferência.
Resultado:
Saldo negativo.
Quando Eventual Consistency funciona
Excelente para:
Feed do Instagram
Likes
Comentários
Catálogo de produtos
Estatísticas
Alguns segundos de atraso não importam.
Quando NÃO funciona
Nunca utilize em:
PIX
Bancos
Bolsa de Valores
Controle de Estoque
Reserva de assentos
Sistemas médicos
Nestes casos:
Strong Consistency
é obrigatória.
Mainframe
DB2 usa:
Commit
Rollback
Locking
Isolation Levels
Há décadas.
Muito antes da moda dos bancos NoSQL.
2. Não Definir Limites do Sistema
Este talvez seja o maior erro.
Imagine uma empresa.
Quem faz RH?
Quem faz Financeiro?
Quem faz Compras?
Agora imagine todos fazendo tudo.
É exatamente isso que acontece em sistemas mal divididos.
Sintoma
Um módulo chamado:
CustomerService
faz:
login
pagamento
envio de email
cadastro
estoque
geração de nota
relatórios
Virou um monólito.
Consequência
Qualquer alteração:
↓
quebra tudo.
Boa arquitetura
Cada domínio possui responsabilidade única.
Order Service
Inventory
Billing
Notification
Shipping
Cada um evolui sozinho.
Conceito
Domain Driven Design
Bounded Context
Single Responsibility
Todos nascem desse princípio.
3. Ignorar Latência
Usuários não medem CPU.
Eles medem tempo.
Exemplo
Pesquisa Google
300 ms
Parece instantânea.
Agora imagine:
4 segundos.
Você já fechou a página.
Latência acumulada
Cliente
↓
API Gateway
↓
Auth
↓
Inventory
↓
Recommendation
↓
Payment
↓
Shipping
↓
DB
Cada chamada adiciona:
20 ms
40 ms
80 ms
100 ms
...
No final:
1 segundo
Sem perceber.
Lei importante
Uma arquitetura com 20 microsserviços pode ser MAIS LENTA que um monólito.
Mainframe
Por isso CICS sempre priorizou:
poucas chamadas
processamento local
transações curtas
4. Subestimar a Carga
Outro erro clássico.
O sistema funciona perfeitamente...
...com 50 usuários.
Mas na Black Friday:
200 mil usuários
Tudo trava.
Perguntas importantes
Quantos usuários?
Quantas requisições?
Picos?
Sazonalidade?
Crescimento anual?
Capacidade
Sempre calcule:
Requests/second
Transactions/minute
IOPS
CPU
RAM
Storage
Network
Exemplo
Sistema:
1000 req/s
Promoção:
15000 req/s
Resultado:
Timeout.
Fila.
Erro 500.
5. Fazer Tudo Sincronamente
Imagine um e-commerce.
Cliente compra.
Sistema:
↓
processa pagamento
↓
envia email
↓
gera nota
↓
atualiza estoque
↓
gera cashback
↓
envia SMS
↓
atualiza BI
Tudo esperando.
O usuário fica olhando.
Melhor abordagem
Pagamento
↓
Resposta imediata
↓
Eventos
↓
↓
Nota
↓
BI
↓
Analytics
↓
Machine Learning
Tudo assíncrono.
Tecnologias
Kafka
RabbitMQ
IBM MQ
SQS
Azure Service Bus
Pulsar
Benefícios
Escalabilidade
Baixa latência
Maior throughput
Resiliência
6. Não Planejar Evolução
Todo sistema muda.
Sempre.
Hoje:
Pix
Amanhã:
Pix Parcelado
Depois:
Pix Internacional
Depois:
IA financeira
Se sua arquitetura não suporta mudança...
Ela morre.
Arquitetura deve ser extensível
Open/Closed Principle
Plug-ins
Feature Flags
Configuration Driven
Interfaces
Strategy Pattern
7. Criar Pontos Únicos de Falha (Single Point of Failure)
Imagine:
1 servidor
↓
Banco
↓
Toda empresa
Servidor cai.
Empresa para.
Alta disponibilidade
Sempre pense em:
Load Balancer
Cluster
Replica
Failover
Geo-redundância
Backup
Mainframe
Sysplex
Parallel Sysplex
GDPS
foram criados exatamente para isso.
8. APIs Mal Projetadas
API é um contrato.
Contrato ruim gera caos.
Exemplo ruim
GET /data
Retorna:
qualquer coisa...
Exemplo melhor
GET /customers/{id}
Resposta consistente.
Documentada.
Versionada.
API deve possuir
Versionamento
Idempotência
Paginação
Rate Limit
Autenticação
Observabilidade
Documentação
9. Ignorar Backup e Recuperação
A pergunta não é:
"Meu sistema vai falhar?"
A pergunta correta é:
"Quando ele vai falhar?"
Recovery é parte da arquitetura
Backup
Snapshot
Point-in-Time Recovery
Replication
Disaster Recovery
Multi Region
Chaos Engineering
Conceitos fundamentais
RPO (Recovery Point Objective)
Quanto de dados você pode perder?
0 minutos
5 minutos
1 hora
RTO (Recovery Time Objective)
Quanto tempo o sistema pode ficar indisponível?
30 segundos
5 minutos
2 horas
Essas metas orientam a escolha da estratégia de backup e recuperação.
Um Décimo Erro que Poucos Mencionam: Falta de Observabilidade
Mesmo uma boa arquitetura pode fracassar se você não consegue enxergar o que acontece em produção.
Os três pilares da observabilidade são:
Logs: registram eventos e erros.
Métricas: mostram CPU, memória, latência, throughput e disponibilidade.
Traces distribuídos: acompanham uma requisição passando por vários serviços.
Ferramentas como Prometheus, Grafana, OpenTelemetry, Jaeger e Elastic Stack ajudam a identificar gargalos antes que eles se transformem em incidentes graves.
Um Décimo Primeiro Erro: Esquecer a Segurança Desde o Início
Segurança não deve ser um complemento adicionado ao final do projeto.
Uma arquitetura moderna precisa considerar desde o início:
Princípio do menor privilégio (Least Privilege)
Autenticação e autorização robustas
Criptografia em trânsito (TLS) e em repouso
Gestão de segredos
Auditoria e rastreabilidade
Proteção contra ataques como SQL Injection, XSS e CSRF
Rate limiting e proteção contra abuso
No ecossistema IBM Z, RACF, TLS, criptografia por hardware e auditoria integrada são exemplos de recursos que incorporam esses princípios há décadas.
O Que Todo Programador COBOL Padawan Deve Aprender
Uma lição importante é que System Design não é exclusivo de microsserviços ou da nuvem. Os princípios fundamentais são universais:
Modelar corretamente o domínio do negócio.
Entender os requisitos funcionais e não funcionais.
Projetar para disponibilidade, escalabilidade e recuperação.
Definir responsabilidades claras entre componentes.
Reduzir acoplamento e aumentar coesão.
Tratar desempenho, segurança e observabilidade como requisitos de primeira classe.
Os grandes sistemas corporativos escritos em COBOL, CICS, IMS e DB2 continuam processando bilhões de transações diariamente porque foram construídos com esses princípios. A tecnologia evolui, mas os fundamentos da boa arquitetura permanecem os mesmos. Um arquiteto experiente não é aquele que conhece mais ferramentas, e sim aquele que consegue prever os problemas antes que eles aconteçam e projetar sistemas preparados para enfrentá-los.
Sem comentários:
Enviar um comentário