 |
| Bellacosa Mainframe apresenta o System Design |
☕ Um Café no Bellacosa Mainframe
🏜️ System Design e a Joia do Nilo — Arquitetura sob a tutela de Jack Colton
Ou: quando você descobre que escalar um sistema é muito parecido com atravessar o deserto — o mapa ajuda, o veículo ajuda, mas aquilo que realmente decide se você chega vivo é saber improvisar quando o plano inevitavelmente dá errado.
Se existe um personagem capaz de ensinar System Design sem abrir um livro de arquitetura, Jack Colton é um candidato maravilhoso.
Em A Joia do Nilo, continuação de Tudo por uma Esmeralda, Jack continua sendo aquele sujeito que parece viver segundo uma arquitetura extremamente simples:
IF problema = TRUE
IMPROVISE
CORRA
SOBREVIVA
CONTINUE
END-IFNão existe Kubernetes no deserto.
Não existe autoscaling automático para camelos.
Não existe botão de rollback quando você tomou a estrada errada.
E definitivamente não existe ServiceNow para abrir um chamado:
INC0000317 — Usuário perseguido no deserto. Severidade 1.
😂
Mas existe algo muito importante:
trade-off.
E System Design é essencialmente a arte de administrar trade-offs.
🏜️ 1. Jack Colton olha para requisitos, não para propaganda
Imagine alguém dizendo:
“Jack, encontrei o veículo mais rápido do mundo!”
Ele provavelmente perguntaria:
“Ótimo. Ele anda no deserto?”
Essa é exatamente a pergunta que falta em muitos projetos.
O mercado apresenta uma tecnologia fantástica:
Kafka!
Kubernetes!
Redis!
MongoDB!
Serverless!
Microservices!
AI Agents!
E alguém imediatamente conclui:
PRECISAMOS DISSO!
Jack Colton provavelmente colocaria os óculos escuros e perguntaria:
“Para quê?”
Essa pequena pergunta poderia economizar milhões em projetos de TI.
Tecnologia não é requisito.
Antes de escolher a solução precisamos conhecer o problema.
🗺️ 2. Antes de atravessar o deserto, descubra onde você está
System Design começa pelos requisitos.
Imagine:
USUÁRIOS ATUAIS 100
USUÁRIOS FUTUROS 10.000
PICO 50 TPS
LATÊNCIA DESEJADA < 500 ms
DISPONIBILIDADE 99,9%
DADOS 500 GB
CRESCIMENTO 20% / anoIsso começa a dizer alguma coisa.
Agora compare com:
USUÁRIOS 50 milhões
PICO 500.000 TPS
DISPONIBILIDADE 99,999%
DADOS Petabytes
OPERAÇÃO GlobalSão desertos completamente diferentes.
Projetar ambos da mesma maneira seria como escolher o mesmo veículo para atravessar Manhattan e o Saara.
🚙 3. Load Balancer — Jack não colocaria todo mundo no mesmo jipe
Imagine 10.000 requisições chegando simultaneamente.
Temos:
USERS
|
v
+--------------+
| LOAD BALANCER|
+--------------+
/ | \
v v v
APP1 APP2 APP3O Load Balancer distribui o tráfego.
Parece perfeito.
Mas Jack perguntaria:
“E se o Load Balancer quebrar?”
Excelente.
Criamos três servidores extremamente resistentes...
e colocamos todos atrás de um único componente.
Temos agora um:
Single Point of Failure.
É como possuir dez veículos de fuga e guardar todas as chaves no bolso do mesmo sujeito.
🐪 4. Autoscaling — mais camelos não resolvem falta de água
Essa talvez seja uma das melhores analogias para arquitetura moderna.
Seu servidor chegou a 90% de CPU?
Adicionamos instâncias.
TRAFFIC
|
v
LOAD BALANCER
/ / / | \ \ \
v v v v v v v
APP APP APP APP APP
|
v
DATABASEExcelente!
Só existe um pequeno detalhe.
Todas estão acessando o mesmo banco.
Resultado:
DATABASE
CPU 100%
CONNECTIONS 100%
I/O 100%
STATUS:
🔥Escalamos o frontend.
E transformamos o banco em gargalo.
Jack Colton provavelmente resumiria:
Mais camelos não criam mais água.
🧊 5. Cache — a cantina que Jack encontrou ontem
Você atravessa uma cidade e encontra água.
Jack marca no mapa:
Água aqui.
No dia seguinte ele passa novamente.
Excelente.
Não precisamos procurar outra vez.
Isso é praticamente cache.
REQUEST
|
v
CACHE ---- HIT ----> RESPONSE
|
MISS
|
v
DATABASEO problema aparece quando alguém fecha a cantina.
O mapa continua dizendo:
Água aqui.
Mas a informação ficou velha.
Temos um stale cache.
Por isso uma das frases mais famosas da computação continua sendo verdadeira:
Existem problemas particularmente difíceis relacionados à invalidação de cache.
Porque cache não significa apenas armazenar informação.
Significa decidir:
quando confiar nela.
🏘️ 6. CDN — coloque suprimentos próximos de quem precisa
Imagine que toda vez que Jack quisesse água no Egito alguém precisasse buscá-la no Brasil.
Funcionaria?
Tecnicamente, sim.
Seria eficiente?
Nem um pouco.
CDNs aproximam determinados conteúdos dos usuários.
Em vez de:
São Paulo
|
|
|
|
+-----------------------> Tokyopodemos distribuir conteúdo por pontos geograficamente próximos.
Resultado:
menos latência, menos tráfego na origem e melhor experiência.
Mas novamente existe trade-off.
Quanto mais cópias distribuímos, mais precisamos pensar em:
sincronização, atualização e invalidação.
📦 7. Queue — Jack não precisa carregar tudo agora
Chegam 100.000 pedidos simultaneamente.
Sem fila:
100.000 REQUESTS
|
v
SERVER
|
💥Com fila:
REQUESTS
|
v
+---------+
| QUEUE |
+---------+
|
v
CONSUMERSA fila funciona como amortecedor.
Ela absorve bursts.
O produtor pode continuar produzindo enquanto consumidores processam dentro de sua capacidade.
Maravilhoso.
Até aparecer:
QUEUE DEPTH
10
100
1.000
10.000
100.000
1.000.000Jack olha para aquilo e pergunta:
“Nós estamos processando ou apenas acumulando o problema?”
Bingo.
Isso é backpressure.
🧨 8. Retry — às vezes insistir piora tudo
Imagine Jack tentando abrir uma porta.
Não abriu.
Ele tenta novamente.
Depois novamente.
Depois 500 pessoas começam a chutar a porta simultaneamente.
A porta não fica mais disponível.
Ela provavelmente deixa de existir. 😂
Em sistemas distribuídos acontece algo semelhante.
REQUEST
|
TIMEOUT
|
RETRY
|
TIMEOUT
|
RETRY
|
RETRY
RETRY
RETRYTemos uma retry storm.
Por isso entram estratégias como:
timeout
exponential backoff
jitter
circuit breaker
retry limitsResiliência não significa:
tente infinitamente.
Significa:
saiba quando parar.
💾 9. Replication — nunca viaje com a única cópia do mapa
Aqui Jack seria excelente DBA.
Temos:
PRIMARY
|
+------ REPLICA 1
|
+------ REPLICA 2Se o primary desaparecer, ainda temos alternativas.
Mas replicação cria uma pergunta interessantíssima:
Quando uma informação muda no primary, quando as réplicas passam a conhecer essa mudança?
Imediatamente?
Depois de alguns milissegundos?
Segundos?
Minutos?
Daí entramos no maravilhoso pântano da:
consistência.
E descobrimos que ter várias cópias é fácil; garantir o comportamento esperado entre elas é a aventura.
🧩 10. Sharding — dividir o mapa
Imagine uma tabela gigantesca.
CUSTOMERS
1
2
3
...
900.000.000Podemos dividir:
SHARD A
customers 1-300M
SHARD B
customers 300M-600M
SHARD C
customers 600M-900MAgora distribuímos armazenamento e processamento.
Fantástico.
Até alguém perguntar:
“Quero uma consulta envolvendo clientes dos três shards.”
😐
Jack lentamente guarda o mapa.
Porque novamente:
ganhamos escala e compramos complexidade.
🦖 11. Agora entra o velho dinossauro IBM Z
Aqui a aventura muda completamente.
Enquanto muita arquitetura moderna nasceu tentando descobrir como coordenar milhares de máquinas menores, o mainframe evoluiu durante décadas com uma obsessão diferente:
executar workloads críticos com altíssima disponibilidade, isolamento, gerenciamento e previsibilidade.
Não significa que IBM Z elimina System Design.
Muito pelo contrário.
Temos:
INTERNET
|
v
API MANAGEMENT
|
v
z/OS Connect
|
+---------+---------+
| |
v v
CICS MQ
| |
v v
Db2 CICS
|
v
Db2Agora aparecem exatamente as perguntas do barco da imagem.
Quanto tráfego?
Qual latência?
Qual TPS?
Qual prioridade?
Qual transação pode esperar?
Qual não pode?
O que ocorre se Db2 estiver degradado?
O que acontece se MQ começar a acumular mensagens?
Qual é nosso recovery?
Como detectaremos o problema?
🎩 12. WLM — o guia da expedição
Aqui encontramos uma das coisas que considero fascinantes no z/OS.
Workload Manager.
Imagine três workloads:
PAGAMENTO PIX
RELATÓRIO GERENCIAL
BATCH ESTATÍSTICOTodos querem recursos.
Mas eles não possuem a mesma importância.
Se estamos no meio de uma tempestade, Jack Colton não perguntaria:
“Quem pediu água primeiro?”
Ele perguntaria:
“Quem precisa dela para continuarmos vivos?”
Essa é uma excelente forma didática de introduzir WLM.
Service classes, goals e importância ajudam o sistema a administrar recursos considerando objetivos do negócio.
🔭 13. Observability — Jack precisa saber onde estão os inimigos
Temos uma aplicação lenta.
A pior resposta possível:
“Parece ser o mainframe.”
😂
Então vamos investigar.
CLIENT
|
| 20 ms
v
API
|
| 40 ms
v
GATEWAY
|
| 30 ms
v
CICS
|
| 2100 ms
v
DB2Agora temos evidência.
Observabilidade transforma:
“acho que...”
em:
“está acontecendo aqui.”
Logs dizem o que aconteceu.
Metrics mostram como o sistema está se comportando.
Traces ajudam a mostrar por onde a transação passou.
Alertas dizem:
Jack, temos problema.
🚨 14. Failover — sempre tenha uma rota de fuga
Jack Colton jamais entraria numa fortaleza sem olhar por onde poderia sair.
Arquitetura deveria possuir a mesma paranoia saudável.
Perguntamos:
E SE A API CAIR?
E SE O BANCO CAIR?
E SE UMA REGIÃO CAIR?
E SE A REDE CAIR?
E SE MQ PARAR?
E SE O STORAGE FALHAR?
E SE O OPERADOR ERRAR?E essa última merece destaque.
Porque componentes falham.
Software possui bugs.
Discos quebram.
Redes desaparecem.
Mas seres humanos também cometem erros.
Por isso arquitetura resiliente não considera somente machine failure.
Considera também human failure.
👨💻 15. People + Process + Technology
E chegamos à pequena placa escondida no navio da imagem.
PEOPLE
PROCESS
TECHNOLOGYEssa talvez seja mais importante do que todas as outras.
Você pode ter:
Kafka
Redis
Kubernetes
OpenShift
MQ
CICS
Db2
WLM
Sysplex
Observability
AIMas às 03:17 surge um alerta.
Ninguém sabe quem é responsável.
O runbook está desatualizado.
O telefone do especialista mudou.
A senha emergencial expirou.
A documentação aponta para um servidor aposentado em 2019.
Então temos uma infraestrutura extremamente sofisticada administrada por:
¯\_(ツ)_/¯🏜️ 16. A maior lição de Jack Colton
Jack não sobrevivia porque possuía sempre o melhor equipamento.
Ele sobrevivia porque conseguia adaptar-se ao ambiente.
Essa é uma belíssima definição de arquitetura resiliente.
Não precisamos construir um sistema incapaz de falhar.
Provavelmente nem conseguiríamos.
Precisamos construir sistemas capazes de:
detectar, absorver, degradar controladamente, recuperar e aprender.
Isso muda completamente a mentalidade.
🥚 Easter egg — A verdadeira Joia do Nilo
Durante todo o artigo estivemos procurando a joia.
Talvez ela estivesse diante de nós desde o início.
Não era:
CACHENem:
QUEUENem:
SHARDINGNem mesmo:
MAINFRAMEA verdadeira joia era:
TRADE-OFF
Porque cada decisão arquitetural é uma troca.
Performance ↔ Cost
Consistency ↔ Availability
Simplicity ↔ Flexibility
Latency ↔ Durability
Scale ↔ Complexity
Automation ↔ ControlE existe uma última lição que Jack Colton provavelmente escreveria na porta do CPD:
Nunca escolha uma tecnologia apenas porque ela atravessou o deserto de outra pessoa. Descubra primeiro qual é o seu deserto.
☕🏜️💻
No Bellacosa Mainframe, System Design não é desenhar uma arquitetura que pareça bonita quando o mar está calmo.
É olhar para as pedras, tubarões, tempestades, gargalos, hot partitions, latência, falhas em cascata e aquele programa COBOL de 1997 que ninguém quer tocar...
colocar os óculos escuros...
e perguntar:
“Certo. Se tudo isso der errado às 03:17, como continuamos navegando?”
Aí, meu caro aventureiro, começa o verdadeiro System Design.
Sem comentários:
Enviar um comentário