 |
| Bellacosa Mainframe e os assassinos sileciosos do system design |
☕ Um Café no Bellacosa Mainframe
Os Assassinos Silenciosos do System Design
O guia do Programador COBOL Padawan para construir sistemas que não explodem quando chegam à produção
Existe um momento muito perigoso na vida de todo projeto de software.
Não é quando o programa apresenta erro de compilação.
Não é quando o JCL retorna JCL ERROR.
Não é quando o COBOL encerra com um S0C7, um S0C4 ou um S806.
O momento mais perigoso acontece muito antes disso.
Acontece naquela reunião aparentemente inocente em que alguém diz:
“É um sistema simples. Vamos começar a programar e depois ajustamos os detalhes.”
Nesse instante, caro Programador COBOL Padawan, uma perturbação surge na Força.
Ou, para os oficiais da Frota Estelar, os sensores da ponte detectam uma anomalia arquitetural se formando perto do núcleo de dobra.
Muitos sistemas não fracassam porque seus programadores desconhecem sintaxe. Eles fracassam porque começaram sem requisitos claros, cresceram sem planejamento, acumularam complexidade desnecessária, ignoraram segurança, não prepararam mecanismos de recuperação e foram colocados em produção sem monitoramento adequado.
No início, tudo parece funcionar.
O sistema cadastra clientes.
A API responde.
O batch termina.
A tela CICS abre.
O SELECT retorna dados.
Todos comemoram.
Entretanto, meses depois, a quantidade de usuários aumenta, o banco de dados cresce, as integrações se multiplicam e aquela pequena aplicação começa a mostrar rachaduras.
As respostas ficam lentas.
O banco atinge níveis perigosos de utilização.
Ninguém consegue localizar os erros.
A equipe tem medo de alterar o código.
Uma mudança de configuração exige nova compilação.
Um servidor cai e leva todo o sistema junto.
O que parecia ser um pequeno cargueiro espacial agora está tentando operar como a USS Enterprise, mas foi construído sem escudos, sem sensores e sem plano de evacuação.
Este artigo é uma viagem completa pelos principais erros de System Design, explicando como eles surgem, por que são perigosos e como evitá-los. A missão é traduzir os conceitos de arquitetura para quem está começando em COBOL, mainframe e sistemas corporativos.
Prepare seu café, ajuste o comunicador e assuma seu posto na ponte.
Temos uma arquitetura para salvar.
1. O que é System Design?
System Design, ou projeto de sistemas, é o processo de decidir como uma solução será estruturada para atender a determinados objetivos.
Não se resume a desenhar caixas e setas em um diagrama.
Também não significa apenas escolher:
linguagem de programação;
banco de dados;
framework;
servidor;
provedor de nuvem.
O projeto de sistemas procura responder perguntas muito mais profundas:
Quem utilizará o sistema?
Quantos usuários serão atendidos?
Qual volume de dados será processado?
O sistema precisa funcionar 24 horas por dia?
O que acontece quando um componente falha?
Como os dados serão protegidos?
Como o ambiente será monitorado?
Como a solução crescerá?
Como uma versão será implantada?
Como recuperar o sistema após um desastre?
Quanto custará manter tudo funcionando?
Em um ambiente mainframe, essas perguntas aparecem há décadas.
Um sistema COBOL corporativo normalmente não é apenas um programa. Ele pode envolver:
transações CICS;
programas batch;
JCL;
arquivos VSAM;
tabelas Db2;
filas IBM MQ;
segurança RACF;
logs SMF;
gerenciamento de carga pelo WLM;
rotinas de recuperação;
interfaces com sistemas externos.
Portanto, System Design é a arte de transformar requisitos de negócio em uma estrutura técnica capaz de funcionar com segurança, desempenho, disponibilidade e possibilidade de evolução.
Um bom projeto não tenta prever o futuro inteiro.
Ele cria uma base suficientemente sólida para que o sistema possa se adaptar sem precisar ser destruído e reconstruído a cada nova necessidade.
2. O primeiro assassino silencioso: começar sem requisitos claros
Um dos erros mais graves é iniciar a programação antes de compreender o problema.
A frase normalmente soa assim:
“Vamos codificar logo para ganhar tempo.”
Na prática, esse atalho costuma produzir o efeito contrário.
Quando os requisitos são vagos, cada pessoa imagina um sistema diferente.
O gestor imagina um portal.
O cliente imagina um aplicativo.
O desenvolvedor imagina uma API.
A infraestrutura imagina uma solução em nuvem.
O analista mainframe imagina uma integração com CICS e Db2.
Todos estão trabalhando, mas cada um está construindo uma nave diferente.
Um exemplo simples
O cliente solicita:
“Precisamos modernizar o sistema de pagamentos.”
A palavra “modernizar” pode significar muitas coisas:
substituir telas 3270 por uma interface web;
expor transações COBOL como APIs;
migrar programas para outra plataforma;
reorganizar o código;
melhorar desempenho;
automatizar implantação;
atualizar a segurança;
criar acesso por dispositivos móveis;
simplesmente documentar o legado.
Sem esclarecimento, a equipe pode passar meses resolvendo o problema errado.
Requisitos funcionais e não funcionais
Os requisitos funcionais descrevem o que o sistema deve fazer.
Exemplos:
cadastrar clientes;
consultar saldo;
emitir boleto;
processar pagamento;
gerar relatório;
cancelar uma transação.
Os requisitos não funcionais descrevem como o sistema deve se comportar.
Exemplos:
responder em menos de dois segundos;
atender dez mil usuários simultâneos;
manter disponibilidade de 99,99%;
criptografar dados sensíveis;
registrar todas as operações;
recuperar o serviço em até quinze minutos.
Muitos projetos documentam apenas as funcionalidades e ignoram os requisitos não funcionais.
Depois descobrem, tarde demais, que o sistema funciona — porém é lento, inseguro ou impossível de operar.
Passo a passo antes de programar
Antes de escrever o primeiro IDENTIFICATION DIVISION, procure responder:
Qual problema de negócio será resolvido?
Quem são os usuários?
Qual volume inicial de dados?
Qual crescimento esperado?
Quais integrações existem?
Qual horário de funcionamento?
Qual nível de indisponibilidade é aceitável?
Quais dados são sensíveis?
Como os erros serão tratados?
Quem dará suporte em produção?
Clareza no início não elimina mudanças.
Ela apenas impede que a equipe viaje em dobra máxima para o quadrante errado.
3. Ignorar escalabilidade desde cedo
Escalabilidade é a capacidade de um sistema continuar funcionando quando sua carga aumenta.
Um projeto pode começar com cem usuários e atingir cem mil.
Uma tabela pode começar com dez mil registros e chegar a bilhões.
Um processo batch que inicialmente trabalha com vinte arquivos pode, anos depois, receber milhares.
O erro está em pensar:
“Quando crescer, nós resolvemos.”
Às vezes isso é possível.
Em outras situações, a solução inicial cria limitações tão profundas que o crescimento exige uma reescrita completa.
Escala vertical e escala horizontal
Escala vertical significa tornar uma máquina mais poderosa:
mais CPU;
mais memória;
mais armazenamento;
processadores mais rápidos.
Escala horizontal significa adicionar mais máquinas ou instâncias para dividir o trabalho.
Em ambientes distribuídos, a escala horizontal é comum.
No mainframe, há décadas existem mecanismos sofisticados de expansão e gerenciamento de carga, como:
múltiplas LPARs;
Parallel Sysplex;
WLM;
compartilhamento de dados;
filas;
particionamento de workloads;
recursos especializados.
O importante não é defender uma única estratégia.
É reconhecer que o crescimento precisa ser considerado.
Exemplo de programa COBOL
Imagine um batch que processa um arquivo sequencial inteiro usando apenas uma etapa e um programa.
No começo:
50 mil registros;
execução em três minutos.
Cinco anos depois:
500 milhões de registros;
execução em nove horas;
janela batch insuficiente.
Talvez o projeto devesse ter considerado:
particionamento;
processamento paralelo;
checkpoints;
retomada após falha;
divisão por faixas;
utilização de banco com índices adequados;
filas de trabalho.
Escalabilidade não significa construir uma arquitetura gigante no primeiro dia.
Significa evitar escolhas que impossibilitem o crescimento.
4. Overengineering: quando a solução é maior que o problema
Overengineering acontece quando criamos uma solução excessivamente complexa para uma necessidade simples.
É o famoso caso de utilizar um torpedo de fótons para abrir uma lata de conservas.
Imagine uma aplicação interna usada por vinte pessoas.
A equipe decide criar:
quinze microsserviços;
três bancos de dados;
um cluster Kubernetes;
Kafka;
Redis;
Elasticsearch;
Service Mesh;
Event Sourcing;
CQRS;
múltiplos pipelines;
dezenas de dashboards.
Tudo isso para cadastrar fornecedores.
A arquitetura parece impressionante em uma apresentação.
Mas agora exige:
mais servidores;
mais especialistas;
mais monitoramento;
mais segurança;
mais custos;
mais pontos de falha.
Complexidade não é sinônimo de maturidade.
O princípio KISS
KISS significa:
Keep It Simple.
Ou, em português:
Mantenha a solução simples.
Uma solução simples tende a ser:
mais fácil de entender;
mais barata;
mais testável;
mais confiável;
mais rápida de corrigir.
Isso não significa escrever código descuidado.
Significa usar apenas a complexidade necessária.
Monólito não é palavrão
Muitas equipes tratam qualquer monólito como tecnologia ultrapassada.
Entretanto, um monólito modular pode ser excelente para diversos cenários.
O problema não é o monólito.
O problema é um monólito sem organização, com dependências caóticas e responsabilidades misturadas.
Da mesma forma, microsserviços não são automaticamente modernos.
Um ambiente de microsserviços mal projetado pode se tornar um monólito distribuído, mais difícil de depurar e mais caro de operar.
A melhor arquitetura não é a mais elegante no diagrama.
É a que atende aos requisitos com o menor nível razoável de complexidade.
5. Negligenciar tolerância a falhas
Todo componente falha.
Discos falham.
Redes falham.
Servidores param.
Programas recebem dados inválidos.
APIs externas ficam indisponíveis.
Filas enchem.
Bancos bloqueiam recursos.
Pessoas cometem erros.
O arquiteto maduro não pergunta:
“Será que vai falhar?”
Ele pergunta:
“Quando falhar, o que acontecerá?”
Falha não pode virar desastre
Uma falha local deveria permanecer local.
Se uma API de consulta de endereço estiver indisponível, isso não deveria necessariamente derrubar todo o sistema de cadastro.
Se um servidor parar, outra instância deveria assumir.
Se um programa batch interromper após processar 80% do arquivo, deveria ser possível retomar do ponto correto.
Padrões importantes
Timeout
Nenhuma chamada deveria esperar eternamente.
Um timeout define quanto tempo o sistema aguardará antes de considerar a operação malsucedida.
Retry
Algumas falhas são temporárias.
Uma nova tentativa pode resolver.
Entretanto, repetir sem controle é perigoso. Mil clientes realizando cinco tentativas podem transformar uma pequena lentidão em colapso completo.
Circuit Breaker
Funciona como um disjuntor.
Quando um serviço começa a falhar repetidamente, o sistema interrompe temporariamente as chamadas para evitar sobrecarga.
Failover
Quando um componente principal falha, outro assume.
Checkpoint
Um processo longo salva pontos de progresso para poder continuar após interrupção.
Dead Letter Queue
Mensagens que não podem ser processadas são desviadas para uma fila de análise, evitando que bloqueiem todo o fluxo.
A tradição do mainframe
A tolerância a falhas está no coração dos ambientes IBM Z.
Conceitos como:
Parallel Sysplex;
Coupling Facility;
GDPS;
replicação;
recuperação de logs;
commit e rollback;
reinício de jobs;
journaling;
gerenciamento de workload;
existem porque sistemas bancários, governamentais e de companhias aéreas não podem simplesmente parar e aguardar alguém reiniciar o computador.
A lição é simples:
Falhar é inevitável. Falhar sem plano é opcional.
6. Ignorar estratégias de cache
Cache é uma camada de armazenamento rápido utilizada para evitar processamento ou acesso repetitivo a fontes mais lentas.
Imagine que dez mil usuários consultem a mesma tabela de códigos de países.
Sem cache, cada requisição pode acessar o banco.
Com cache, a informação pode ser lida uma vez e reutilizada.
Isso reduz:
latência;
carga no banco;
consumo de CPU;
tráfego de rede;
custos.
Tipos de cache
O cache pode existir:
no navegador;
na aplicação;
em memória;
em servidores como Redis;
em proxies;
em CDNs;
em estruturas internas do banco;
em subsistemas mainframe.
O lado difícil
Cache traz um problema delicado:
Como garantir que os dados não fiquem desatualizados?
Se o preço de um produto mudar no banco, quando o cache será atualizado?
Estratégias comuns incluem:
tempo de expiração;
invalidação explícita;
atualização após gravação;
leitura através do cache;
atualização antecipada.
Existe uma velha piada entre programadores:
Há duas coisas difíceis em computação: invalidar cache, nomear coisas e erros de contagem.
Sim, a frase diz duas coisas e lista três.
Esse é o easter egg clássico.
Cache não conserta consulta ruim
Adicionar cache sobre uma arquitetura defeituosa pode apenas esconder o problema.
Primeiro, ajuste:
índices;
consultas;
modelo de dados;
volume retornado.
Depois, utilize cache onde houver benefício real.
7. Projeto ruim de banco de dados
O banco de dados frequentemente se torna o coração e o gargalo do sistema.
Um modelo mal projetado pode causar:
consultas lentas;
duplicidade;
inconsistência;
bloqueios;
dificuldade de manutenção;
crescimento descontrolado.
Erros comuns
Falta de índices
Uma consulta por CPF em uma tabela com milhões de registros pode exigir varredura completa se não houver índice adequado.
Índices demais
Índices aceleram leitura, mas também ocupam espaço e aumentam o custo de inserções, atualizações e exclusões.
Uso indiscriminado de SELECT *
Buscar todas as colunas desperdiça:
I/O;
memória;
rede;
CPU.
Solicite apenas os dados necessários.
Tipos inadequados
Armazenar datas como texto ou valores numéricos como caracteres cria problemas de validação, ordenação e desempenho.
Ausência de integridade
Chaves primárias, estrangeiras, restrições e validações ajudam a impedir dados inválidos.
Transações longas
Uma transação aberta por muito tempo pode manter locks e afetar outros usuários.
No Db2
O programador COBOL precisa conhecer a importância de:
índices;
EXPLAIN;RUNSTATS;REORG;planos de acesso;
cardinalidade;
commits;
níveis de isolamento;
cursores;
tabelas particionadas.
Um SQL correto do ponto de vista sintático pode ser desastroso do ponto de vista operacional.
A consulta retorna o resultado.
Mas talvez consuma milhões de leituras para localizar vinte linhas.
O banco não deve ser tratado como um depósito onde jogamos dados.
Ele é um motor que precisa ser modelado, observado e ajustado.
8. Ignorar segurança
Segurança não deve ser adicionada no final do projeto como um acessório.
Ela precisa acompanhar todo o ciclo de vida.
Cada atalho pode criar uma superfície de ataque.
Autenticação e autorização
Autenticação responde:
Quem é você?
Autorização responde:
O que você pode fazer?
Uma pessoa pode estar corretamente autenticada e ainda assim não possuir permissão para consultar salários, alterar limites ou excluir registros.
Princípio do menor privilégio
Cada usuário, programa ou serviço deve receber apenas as permissões necessárias.
Nada além disso.
Uma aplicação que precisa apenas consultar uma tabela não deveria ter permissão para apagá-la.
Criptografia
Dados precisam ser protegidos:
em trânsito;
em repouso;
durante backups;
em arquivos temporários;
em logs.
Segredos não pertencem ao código
Senhas, tokens e chaves não devem aparecer em programas ou repositórios.
Nada de:
01 WS-PASSWORD PIC X(20) VALUE 'ADMIN123'.
Além de inseguro, isso transforma qualquer troca de senha em alteração de código.
Mainframe e segurança
No IBM Z, a proteção pode envolver:
RACF;
SAF;
perfis de recursos;
MFA;
TLS;
ICSF;
Crypto Express;
auditoria SMF;
separação de funções.
Entretanto, possuir ferramentas poderosas não garante segurança.
Configuração incorreta, privilégios excessivos e ausência de revisão continuam sendo riscos.
Segurança é tecnologia, processo e disciplina.
9. Não ter monitoramento, logs e observabilidade
Um sistema sem monitoramento é como a Enterprise atravessando uma nebulosa com os sensores desligados.
Talvez a nave esteja bem.
Talvez esteja a segundos de uma colisão.
Sem telemetria, ninguém sabe.
Logs
Logs registram eventos importantes:
início e fim de processamento;
erros;
decisões;
identificadores;
mensagens recebidas;
duração de operações.
Um bom log precisa ser útil.
Mensagens como:
“Erro inesperado.”
ajudam muito pouco.
Melhor seria registrar:
operação;
horário;
módulo;
código do erro;
contexto;
identificador da transação.
Naturalmente, sem expor senhas ou dados sensíveis.
Métricas
Métricas mostram valores ao longo do tempo:
CPU;
memória;
transações por segundo;
tempo médio de resposta;
quantidade de erros;
tamanho de fila;
uso de conexões;
duração do batch.
Tracing
Em sistemas distribuídos, uma única operação pode atravessar diversos serviços.
Tracing permite acompanhar a jornada da requisição.
Observabilidade no mainframe
Podemos relacionar esse universo a:
SMF;
RMF;
OMEGAMON;
SDSF;
logs do CICS;
estatísticas do Db2;
mensagens JES;
registros de MQ;
relatórios de WLM.
O objetivo é responder:
O que aconteceu?
Quando aconteceu?
Onde aconteceu?
Qual componente foi afetado?
Quantos usuários sofreram impacto?
Qual foi a causa?
O problema está piorando?
Se a equipe só descobre uma falha quando o cliente telefona, o sistema não está verdadeiramente monitorado.
10. Configurações hardcoded
Hardcoding ocorre quando valores específicos de ambiente são gravados diretamente no código.
Exemplos:
endereço de servidor;
senha;
diretório;
fila;
porta;
nome de banco;
limite operacional;
e-mail;
URL.
Por que isso é ruim?
Porque o código fica preso ao ambiente.
Para mover de desenvolvimento para teste, talvez seja necessário alterar e recompilar.
Para trocar um servidor, nova mudança.
Para ajustar timeout, novo deploy.
Isso aumenta riscos e reduz flexibilidade.
Estratégia correta
Separar:
código;
configuração;
segredo.
Configurações podem ficar em:
arquivos externos;
variáveis de ambiente;
tabelas de parâmetros;
sistemas de gestão de configuração;
cofres de segredos;
propriedades de runtime.
No mundo COBOL e mainframe, essa separação também pode envolver:
PARM de JCL;
SYSIN;
DDs;
arquivos de controle;
tabelas Db2;
variáveis simbólicas;
parâmetros de transação.
O mesmo programa pode operar em vários ambientes sem alteração do fonte.
Essa é uma característica valiosa de sistemas bem projetados.
11. Não testar em escala realista
O notebook do desenvolvedor não é a produção.
No ambiente local:
há poucos dados;
apenas um usuário;
quase nenhuma concorrência;
rede rápida;
banco vazio;
recursos disponíveis.
Em produção:
milhares de usuários;
milhões de registros;
chamadas simultâneas;
períodos de pico;
integrações lentas;
falhas intermitentes.
Um sistema pode funcionar perfeitamente no teste funcional e colapsar sob carga.
Tipos de teste
Teste de carga
Verifica o comportamento sob volume esperado.
Teste de estresse
Aumenta a carga até localizar o limite.
Teste de pico
Simula aumento repentino de uso.
Teste de longa duração
Avalia vazamentos de memória, degradação e acúmulo de recursos.
Teste de concorrência
Identifica condições de corrida, locks e conflitos.
Teste de recuperação
Confirma se o sistema volta corretamente após falha.
Chaos Engineering
Introduz falhas controladas para verificar a resiliência.
Por exemplo:
derrubar uma instância;
atrasar uma chamada;
bloquear uma dependência;
simular perda de rede;
encher uma fila.
No mainframe, também é essencial testar:
grandes massas;
duração da janela batch;
contenção Db2;
transações CICS;
reinício de jobs;
checkpoints;
indisponibilidade de datasets;
falha de comunicação MQ.
Produção não deveria ser o primeiro teste de escala.
Quando isso acontece, o cliente se torna parte involuntária da equipe de QA.
12. O erro invisível: monitorar tecnologia, mas ignorar o negócio
Muitas equipes monitoram CPU, memória e disco.
Mas não sabem responder:
Quantos pagamentos foram processados?
Quantas vendas foram perdidas?
Quantos clientes abandonaram a operação?
Quantas transações falharam por regra de negócio?
Qual valor financeiro ficou represado?
O sistema pode estar tecnicamente saudável e ainda assim falhar na missão.
Imagine que todos os servidores estejam verdes no painel, mas uma regra errada esteja rejeitando metade dos pedidos.
A infraestrutura diz:
“Tudo normal.”
O negócio diz:
“Estamos perdendo dinheiro.”
Por isso, métricas técnicas e de negócio precisam caminhar juntas.
A ponte da Enterprise não monitora apenas o motor de dobra.
Ela também monitora destino, tripulação, missão e ameaças.
13. O custo também faz parte da arquitetura
Uma arquitetura pode funcionar e ainda assim ser inviável financeiramente.
Recursos ociosos, bancos superdimensionados, tráfego excessivo, logs sem retenção controlada e componentes desnecessários aumentam despesas.
Na nuvem, cada decisão pode gerar custo recorrente:
processamento;
armazenamento;
transferência;
chamadas;
serviços gerenciados;
licenciamento.
No mainframe, também existem questões de:
consumo de CPU;
MSU;
janelas;
classes de serviço;
licenças;
capacidade;
uso de processadores especializados.
Um bom arquiteto não pensa apenas:
“Funciona?”
Ele também pergunta:
“É sustentável?”
A melhor solução equilibra:
desempenho;
confiabilidade;
segurança;
simplicidade;
custo.
14. Um roteiro prático para projetar melhor
Aqui está um pequeno plano de missão para o Programador COBOL Padawan.
Etapa 1 — Compreenda o problema
Converse com usuários e responsáveis pelo negócio.
Evite começar pela tecnologia.
Etapa 2 — Levante requisitos funcionais
Liste as operações que o sistema deverá executar.
Etapa 3 — Levante requisitos não funcionais
Defina:
desempenho;
volume;
disponibilidade;
segurança;
recuperação;
auditoria.
Etapa 4 — Identifique dados e integrações
Pergunte:
De onde os dados vêm?
Onde serão armazenados?
Quem poderá acessá-los?
Quais sistemas dependem deles?
Etapa 5 — Desenhe uma solução simples
Comece com a menor arquitetura capaz de atender aos requisitos.
Etapa 6 — Mapeie pontos de falha
Para cada componente, pergunte:
“O que acontece se ele parar?”
Etapa 7 — Planeje observabilidade
Defina logs, métricas, alertas e painéis antes da produção.
Etapa 8 — Separe configuração do código
Prepare a solução para múltiplos ambientes.
Etapa 9 — Teste com volume realista
Não teste apenas o caminho feliz.
Etapa 10 — Revise segurança
Aplique menor privilégio, criptografia e auditoria.
Etapa 11 — Documente decisões
Registre por que determinada alternativa foi escolhida.
Isso evita que, anos depois, alguém veja uma solução estranha e a substitua sem compreender o contexto.
Etapa 12 — Evolua gradualmente
Arquitetura não é um monumento congelado.
Ela deve ser revisada conforme o negócio e a tecnologia evoluem.
15. Curiosidades da sala de máquinas
Curiosidade 1 — Mainframes já faziam “cloud” antes do nome existir
Compartilhamento de recursos, virtualização, isolamento e gerenciamento centralizado são práticas antigas no mainframe.
O termo mudou.
Muitos princípios permaneceram.
Curiosidade 2 — Filas não são novidade
Mensageria assíncrona parece moderna, mas sistemas corporativos utilizam filas e processamento desacoplado há décadas.
IBM MQ é um exemplo clássico dessa filosofia.
Curiosidade 3 — O batch continua vivo
Mesmo com APIs e eventos, processamento batch continua essencial para:
fechamento financeiro;
faturamento;
conciliação;
geração de relatórios;
tratamento de grandes volumes.
A diferença é que batch moderno pode ser integrado a pipelines, APIs e eventos.
Curiosidade 4 — Simplicidade exige experiência
Criar algo complicado é relativamente fácil.
Criar uma solução simples que atenda aos requisitos exige entendimento profundo.
É como a ponte da Enterprise: o painel parece organizado porque uma enorme complexidade foi cuidadosamente controlada abaixo do convés.
16. Easter egg da Frota Estelar
Em muitos episódios de Star Trek, a Enterprise encontra tecnologias extremamente poderosas construídas por civilizações avançadas.
Entretanto, o perigo raramente está apenas na tecnologia.
O problema aparece quando:
ninguém compreende os limites;
não existem controles;
a tripulação ignora sinais;
alguém tenta obter poder rapidamente;
uma falha pequena se propaga.
Isso é System Design.
Uma arquitetura sofisticada sem compreensão pode ser mais perigosa que uma solução simples.
O melhor oficial de engenharia não é aquele que instala mais componentes.
É aquele que mantém a nave funcionando, conhece seus limites e sabe exatamente o que fazer quando uma luz vermelha aparece no painel.
Como diria Montgomery Scott em espírito:
Você não pode mudar as leis da física, capitão.
Na engenharia de software, também não podemos ignorar:
latência;
concorrência;
falhas;
volume;
capacidade;
custo.
Podemos administrá-los.
Nunca eliminá-los por decreto.
Conclusão — O sistema não quebra de repente
Os grandes problemas arquiteturais raramente chegam anunciados.
Eles crescem silenciosamente.
Uma consulta sem índice parece inofensiva enquanto a tabela é pequena.
Uma configuração hardcoded parece conveniente enquanto existe apenas um ambiente.
A ausência de cache não incomoda enquanto há poucos usuários.
A falta de logs passa despercebida enquanto nada falha.
A inexistência de failover parece aceitável enquanto o servidor está funcionando.
Depois, um dia, tudo converge.
O tráfego aumenta.
O banco fica lento.
A aplicação gera timeout.
Os retries sobrecarregam ainda mais o sistema.
A fila cresce.
Os logs são insuficientes.
A equipe não consegue identificar a causa.
A direção pede uma previsão.
O cliente reclama.
E alguém diz:
“Precisamos reescrever tudo.”
Na realidade, o desastre começou meses ou anos antes, em pequenas decisões que pareciam não ter importância.
O verdadeiro objetivo de System Design não é criar diagramas bonitos nem utilizar todas as tecnologias da moda.
É construir sistemas capazes de:
cumprir sua missão;
resistir a falhas;
crescer com controle;
proteger dados;
ser observados;
ser mantidos;
evoluir sem caos.
Para o Programador COBOL Padawan, compreender arquitetura é o passo que transforma alguém que apenas escreve programas em um profissional que entende sistemas.
O COBOL pode processar a regra.
O JCL pode executar o job.
O Db2 pode armazenar os dados.
O CICS pode receber a transação.
O MQ pode transportar a mensagem.
Mas é o projeto de sistemas que faz todas essas partes trabalharem juntas.
Na Frota Estelar, uma nave não é apenas o motor de dobra.
É a combinação de propulsão, sensores, escudos, comunicação, suporte à vida, segurança, comando e uma tripulação treinada.
No mundo corporativo, a arquitetura também depende de integração, observabilidade, resiliência, dados, processos e pessoas.
Antes de liberar a próxima versão, pare diante do painel e faça a pergunta mais importante:
“Estamos construindo apenas algo que funciona hoje, ou um sistema capaz de sobreviver à missão de amanhã?”
Porque o melhor sistema não é aquele que nunca falha.
É aquele que foi projetado para continuar sua jornada quando o inesperado inevitavelmente aparecer no horizonte.
Vida longa e próspera aos seus programas, aos seus jobs e às suas arquiteturas.
Sem comentários:
Enviar um comentário