 |
| Bellacosa Mainframe investiga a arquitetura de microservicos da netflix |
☕ Um Café no Bellacosa Mainframe
CSI Netflix: A Arquitetura de Microserviços Investigada por um Programador COBOL
Quando um Simples Clique no Botão “Assistir” Abre uma Cena do Crime Distribuída Entre APIs, Filas, Bancos, Caches, Eventos e Milhares de Servidores
Às 02h17 da madrugada, a cidade de Nova York parecia executar seu eterno processamento batch.
As avenidas continuavam recebendo transações. Os semáforos alternavam estados como flags de controle. Táxis percorriam rotas imprevisíveis, enquanto milhões de janelas iluminadas lembravam terminais conectados a um sistema gigantesco cuja documentação havia sido perdida décadas atrás.
No laboratório do CSI New York, uma nova ocorrência acabava de chegar.
Não havia sangue.
Não havia arma.
Não havia sequer uma vítima humana.
O relatório dizia apenas:
“O usuário pressionou o botão Assistir, mas o vídeo demorou três segundos para começar.”
Para uma pessoa comum, três segundos não seriam um crime.
Para uma plataforma global de streaming, três segundos poderiam representar abandono, perda de audiência, quebra de experiência, sobrecarga em algum serviço ou indício de uma falha distribuída prestes a contaminar milhões de sessões.
Sobre a mesa de análise estava um diagrama com o título:
Microservice Architecture at Netflix
O investigador observou a sequência de componentes:
cliente;
balanceador de carga;
API Gateway;
microserviços;
cache;
banco de dados;
pipeline de eventos;
Kafka;
Spark;
Elasticsearch;
Amazon S3;
Hadoop;
sistema de notificações.
Ao lado dele, um programador COBOL iniciante segurava uma caneca de café e tentava encontrar a PROCEDURE DIVISION.
Não havia.
Também não havia JCL.
Nenhum EXEC CICS.
Nenhum CALL explícito mostrando quem chamava quem.
Mesmo assim, o sistema funcionava.
Ou pelo menos deveria funcionar.
O investigador apontou para o diagrama e declarou:
“Em uma arquitetura distribuída, todo componente é uma testemunha. O problema é que algumas testemunhas mentem, outras desaparecem e várias mudam de endereço durante o interrogatório.”
Era hora de reconstruir a ocorrência.
1. A primeira evidência: o clique não é a transação completa
Quando um usuário abre a Netflix em uma televisão, celular, navegador, tablet ou console e pressiona o botão Assistir, parece que apenas um vídeo está sendo solicitado.
Por trás da interface, porém, diversas perguntas precisam ser respondidas:
O usuário está autenticado?
A assinatura continua ativa?
Qual perfil está sendo utilizado?
O conteúdo está disponível naquele país?
A classificação etária permite a reprodução?
Qual idioma deve ser selecionado?
Há legenda adequada?
O dispositivo suporta HDR?
Qual resolução é recomendada?
A conexão permite 4K?
De onde o vídeo será entregue?
Em que ponto o usuário parou?
A reprodução deve ser registrada no histórico?
Esse evento deve influenciar recomendações futuras?
Um único clique inicia uma cadeia de decisões.
No universo COBOL, poderíamos imaginar um programa monolítico:
PERFORM VALIDAR-USUARIO
PERFORM VALIDAR-ASSINATURA
PERFORM CONSULTAR-PERFIL
PERFORM CONSULTAR-CATALOGO
PERFORM VALIDAR-REGIAO
PERFORM LOCALIZAR-CONTEUDO
PERFORM REGISTRAR-REPRODUCAO
PERFORM INICIAR-STREAMING
Em uma arquitetura de microserviços, essas responsabilidades podem estar espalhadas por diversos programas independentes, executados em máquinas diferentes, atualizados por equipes distintas e comunicando-se por rede.
A operação deixa de ser um grande PERFORM local e passa a ser uma investigação distribuída.
Essa distinção é fundamental.
Quando um parágrafo COBOL chama outro dentro do mesmo programa, o custo costuma ser pequeno e previsível. Quando um serviço chama outro pela rede, surgem novos suspeitos:
latência;
perda de pacotes;
indisponibilidade;
timeout;
autenticação;
serialização;
incompatibilidade de versões;
congestionamento;
repetição de requisições;
respostas parciais.
A rede não é apenas um cabo entre dois sistemas.
A rede é uma variável de negócio.
2. O cliente: onde a ocorrência começa
O primeiro componente da arquitetura é o cliente.
Ele pode ser:
navegador web;
aplicativo Android ou iOS;
Smart TV;
videogame;
receptor multimídia;
tablet;
dispositivo antigo com poucos recursos.
Um erro comum do iniciante é imaginar que todos os clientes possuem capacidade semelhante.
Não possuem.
Uma Smart TV de entrada fabricada anos atrás pode ter pouca memória, processador limitado e sistema operacional desatualizado. Um smartphone moderno pode realizar tarefas muito mais sofisticadas. Um console de videogame possui características diferentes de um navegador.
O backend não deve simplesmente responder:
{
"video": "filme.mp4"
}
Ele precisa considerar as características do dispositivo, da sessão e da rede.
Uma resposta mais realista pode incluir:
{
"titleId": "8732451",
"profile": "adulto",
"audio": "pt-BR",
"subtitle": "pt-BR",
"resolution": "1080p",
"hdr": false,
"resumePosition": 1842,
"streamingProfile": "adaptive"
}
O cliente é a primeira testemunha, mas nem sempre é confiável.
Ele pode estar:
com relógio incorreto;
usando uma versão antiga;
operando em uma rede instável;
repetindo uma requisição;
enviando dados incompletos;
tentando acessar uma API descontinuada.
Por isso, o backend nunca deve confiar cegamente em tudo que recebe.
No mainframe, essa ideia já existe há décadas: validar campos, proteger limites, conferir códigos, verificar autorização e tratar entradas como potencialmente problemáticas.
A tecnologia muda. A prudência permanece.
3. Elastic Load Balancer: o policial controlando a multidão
Depois que a requisição deixa o cliente, ela normalmente passa por um balanceador de carga.
No diagrama aparece o AWS Elastic Load Balancer, frequentemente abreviado como ELB.
Sua função é distribuir requisições entre várias instâncias de uma aplicação.
Imagine três servidores:
Servidor A
Servidor B
Servidor C
Sem balanceamento, todas as chamadas poderiam cair no Servidor A:
A: 100%
B: 0%
C: 0%
O resultado seria previsível:
Servidor A sobrecarregado
Servidor B ocioso
Servidor C ocioso
Usuários irritados
Equipe de plantão acordada
Com balanceamento:
A: 34%
B: 33%
C: 33%
O balanceador também realiza verificações de saúde.
Se o Servidor B deixa de responder:
A: saudável
B: fora de serviço
C: saudável
O tráfego é direcionado apenas para A e C.
No mundo IBM Z, o programador COBOL pode comparar esse comportamento, de forma conceitual, com mecanismos de distribuição e gerenciamento de carga encontrados em ambientes como:
WLM;
CICSplex;
Sysplex;
roteamento entre regiões CICS;
múltiplas instâncias de aplicações;
balanceamento de workloads.
Não são tecnologias idênticas, mas enfrentam uma pergunta semelhante:
“Para onde esta unidade de trabalho deve ser enviada?”
Curiosidade da perícia
O balanceador não precisa compreender toda a regra de negócio. Ele não precisa saber se o usuário está assistindo a um documentário ou a um anime.
Ele precisa saber coisas como:
qual servidor está saudável;
qual rota deve receber a chamada;
se a conexão deve ser encerrada;
se há capacidade disponível;
se a comunicação é segura.
Ele é o policial na entrada do prédio.
Não resolve o caso, mas impede que todas as testemunhas entrem pela mesma porta ao mesmo tempo.
4. API Gateway: a recepção blindada
Depois do balanceador, encontramos o API Gateway.
Ele funciona como um ponto central de entrada para as APIs.
Sem Gateway, o cliente poderia precisar conhecer dezenas de serviços:
login.netflix.exemplo
catalogo.netflix.exemplo
perfil.netflix.exemplo
pagamento.netflix.exemplo
recomendacao.netflix.exemplo
historico.netflix.exemplo
Isso criaria forte acoplamento entre o aplicativo e a estrutura interna.
Com um Gateway, o cliente acessa uma entrada controlada:
api.netflix.exemplo
O Gateway analisa a rota:
GET /profiles
GET /catalog
GET /recommendations
POST /playback/start
E encaminha cada requisição ao serviço correspondente.
Além do roteamento, o Gateway pode cuidar de:
autenticação;
autorização;
controle de taxa;
logs;
métricas;
transformação de mensagens;
compressão;
versionamento;
validação de tokens;
proteção contra abuso.
Exemplo de rate limiting
Um cliente normal pode fazer algumas requisições por segundo.
Um robô defeituoso pode tentar:
100.000 requisições por segundo
O Gateway pode interromper o abuso:
HTTP/1.1 429 Too Many Requests
Isso protege os serviços internos.
Em uma analogia mainframe, o Gateway reúne funções que podem lembrar, em diferentes níveis, componentes como:
front-end transacional;
camada de segurança;
validação RACF;
roteamento;
controle de acesso;
filtros;
monitoramento;
limites operacionais.
Ele não substitui o RACF nem é um CICS. A comparação serve apenas para ajudar o iniciante a localizar mentalmente a função.
Dica para o padawan COBOL
Nunca confunda “ponto único de entrada” com “ponto único de falha”.
Se existe apenas uma instância do Gateway e ela morre, toda a plataforma fica inacessível.
Por isso, o Gateway também deve ser:
replicado;
balanceado;
monitorado;
escalável;
tolerante a falhas.
Em sistemas críticos, até o porteiro precisa de substituto.
5. Microserviços: desmontando o monólito
Chegamos ao coração da arquitetura.
Um monólito reúne muitas funções dentro de uma única aplicação.
Poderíamos ter:
NETFLIX-APP
├── Login
├── Perfis
├── Catálogo
├── Busca
├── Pagamentos
├── Histórico
├── Recomendações
├── Legendas
└── Streaming
No começo, esse modelo pode ser simples.
Uma única aplicação.
Um único pacote.
Um único processo de implantação.
Mas, conforme o sistema cresce, o monólito pode se tornar pesado:
milhões de linhas;
dependências difíceis;
testes demorados;
deploys arriscados;
equipes bloqueando umas às outras;
necessidade de escalar tudo, mesmo quando apenas uma função está sobrecarregada.
Os microserviços quebram o sistema em unidades menores:
Serviço de Login
Serviço de Perfil
Serviço de Catálogo
Serviço de Busca
Serviço de Recomendação
Serviço de Cobrança
Serviço de Reprodução
Serviço de Histórico
Cada serviço pode possuir:
código próprio;
ciclo de vida próprio;
equipe responsável;
banco ou armazenamento específico;
métricas;
versionamento;
capacidade de escala independente.
Se o serviço de recomendações está sobrecarregado, ele pode receber mais instâncias sem que o serviço de cobrança também precise crescer.
A grande armadilha
Microserviços não eliminam complexidade.
Eles redistribuem a complexidade.
O monólito concentra problemas dentro do programa.
Os microserviços espalham problemas por:
rede;
contratos de API;
autenticação;
logs;
filas;
bancos;
versões;
observabilidade;
deploys;
tolerância a falhas.
É como desmontar um grande arquivo sequencial em centenas de datasets.
Você ganha flexibilidade.
Também ganha centenas de nomes, catálogos, permissões, políticas e pontos de falha para administrar.
A arquitetura de microserviços não deve ser adotada porque está na moda. Ela faz sentido quando o domínio, a escala, a organização e a necessidade de independência justificam o custo operacional.
Evidência número 5-A
Um monólito bem projetado é melhor do que uma coleção de microserviços mal projetados.
Esse detalhe costuma desaparecer das apresentações corporativas.
6. Service Discovery: procurando suspeitos que mudam de endereço
Em um ambiente distribuído, os serviços nascem e morrem constantemente.
Uma instância do serviço de catálogo pode estar em:
10.20.14.8:8080
Após um novo deploy, outra instância surge em:
10.20.19.42:8080
Mais tarde, o auto scaling cria novas cópias:
10.20.21.10:8080
10.20.21.11:8080
10.20.21.12:8080
Como os demais serviços descobrem esses endereços?
Não é recomendável gravá-los no código:
MOVE '10.20.14.8' TO WS-ENDERECO-SERVICO.
Esse seria o equivalente distribuído de colocar o nome físico de um dataset em 300 programas COBOL.
A descoberta de serviços mantém um registro atualizado.
Cada serviço informa:
Nome: recommendation-service
Estado: saudável
Endereço: 10.20.21.10
Porta: 8080
Versão: 4.7
Na história da Netflix, o Eureka tornou-se uma referência conhecida para esse tipo de registro e descoberta.
Quando um serviço precisa localizar outro, consulta o registro ou utiliza informações mantidas em cache.
O paralelo com o mainframe
No mainframe, o programador raramente precisa conhecer o endereço físico exato de cada recurso de hardware. Há camadas de abstração, catálogos, subsistemas, definições e mecanismos de roteamento.
O Service Discovery segue uma lógica semelhante:
“Chame o serviço pelo nome lógico; deixe a infraestrutura descobrir onde ele está.”
7. Cache: a impressão digital da performance
O cache é uma das peças mais importantes de sistemas de alta escala.
Imagine que milhões de pessoas abram a mesma série popular.
Sem cache, cada requisição poderia consultar o banco:
SELECT *
FROM TITULOS
WHERE ID_TITULO = 8732451;
Multiplique isso por milhões.
O banco acabaria interrogado até confessar crimes que não cometeu.
Com cache, o resultado mais acessado fica temporariamente em memória:
Chave: TITULO:8732451
Valor: metadados do conteúdo
Tempo de vida: 10 minutos
A primeira requisição consulta o banco.
As próximas utilizam a memória.
Como a memória é muito mais rápida, a latência cai e o banco é protegido.
O que pode ficar em cache?
informações de perfil;
metadados de filmes;
títulos populares;
configurações;
sessões;
autorizações temporárias;
resultados de busca;
recomendações;
preferências;
disponibilidade regional.
O problema da evidência antiga
Cache também cria riscos.
Imagine que o usuário altere o nome do perfil:
Antes: Vagner
Depois: Conan do Mainframe
O banco foi atualizado, mas o cache continua contendo o valor antigo.
Durante algum tempo, o sistema pode mostrar:
Vagner
Isso é uma inconsistência temporária.
As principais estratégias incluem:
expiração por tempo;
invalidação após alteração;
atualização do cache;
cache-aside;
write-through;
write-behind.
Cache-aside, passo a passo
A aplicação procura a informação no cache.
Se encontrar, retorna imediatamente.
Se não encontrar, consulta o banco.
Armazena o resultado no cache.
Retorna a resposta.
Pseudocódigo:
DADO = CACHE.GET(CHAVE)
SE DADO NÃO EXISTE
DADO = BANCO.SELECT(CHAVE)
CACHE.PUT(CHAVE, DADO)
FIM-SE
Para o programador COBOL, a lógica lembra o uso de tabelas em memória, áreas compartilhadas, buffers e recursos temporários para evitar acessos repetidos a dispositivos mais lentos.
8. Banco de dados: o cofre das evidências persistentes
O banco guarda informações que não podem desaparecer quando um processo termina.
Entre elas:
usuários;
perfis;
assinaturas;
histórico;
preferências;
metadados;
direitos de exibição;
dados financeiros;
configurações.
Uma arquitetura de larga escala raramente utiliza apenas um banco universal para tudo.
Diferentes necessidades podem exigir diferentes soluções:
dados relacionais;
chave-valor;
documentos;
séries temporais;
grafos;
pesquisa textual;
armazenamento de objetos.
Esse princípio é chamado, em muitos contextos, de persistência poliglota.
Não significa usar dezenas de bancos por entusiasmo tecnológico. Significa escolher o mecanismo adequado para cada tipo de problema.
O alerta do laboratório
Cada banco adicional aumenta:
conhecimento necessário;
manutenção;
monitoramento;
backup;
recuperação;
segurança;
custos;
complexidade operacional.
No mainframe, o ambiente costuma valorizar padronização e governança forte. Em plataformas distribuídas, a liberdade tecnológica precisa ser equilibrada por disciplina arquitetural.
Caso contrário, a empresa termina com:
37 bancos
14 formatos
9 sistemas de mensageria
0 pessoas que entendem o conjunto completo
Esse é o tipo de cena que nem o CSI deseja encontrar.
9. Kafka e arquitetura orientada a eventos
Quando o usuário pressiona Play, vários sistemas podem precisar saber que a reprodução começou.
Uma abordagem síncrona seria:
Serviço de Reprodução
chama Histórico
chama Métricas
chama Recomendações
chama Notificações
chama Auditoria
chama Analytics
O problema aparece quando um desses serviços está lento ou indisponível.
A reprodução poderia ficar presa esperando um sistema de analytics responder.
Em uma arquitetura orientada a eventos, o serviço publica uma ocorrência:
{
"eventType": "PLAYBACK_STARTED",
"userId": "U92837",
"profileId": "P4",
"titleId": "8732451",
"timestamp": "2026-07-26T02:17:31Z"
}
O evento é enviado para um sistema de mensageria ou streaming como o Kafka.
Diversos consumidores podem receber a informação:
Consumidor de Histórico
Consumidor de Recomendações
Consumidor de Métricas
Consumidor de Auditoria
Consumidor de Notificações
O produtor não precisa conversar diretamente com todos.
Isso reduz acoplamento.
Analogia com MQ
Para um programador COBOL, Kafka pode lembrar alguns princípios de mensageria conhecidos no IBM MQ:
produtor;
consumidor;
desacoplamento;
comunicação assíncrona;
persistência;
reprocessamento;
filas ou tópicos;
confirmação;
tratamento de falhas.
Mas Kafka não é simplesmente “um MQ moderno”.
O Kafka trabalha de maneira muito associada a logs distribuídos, partições, offsets, retenção e processamento de fluxos.
No Kafka, mensagens podem permanecer disponíveis por um período e ser relidas.
Isso permite reconstruir estados, reprocessar eventos e alimentar diferentes consumidores.
O offset como marcador de página
Cada consumidor acompanha até onde leu.
Imagine:
Offset 1001
Offset 1002
Offset 1003
Offset 1004
Se o consumidor parar após o 1003, poderá reiniciar a partir daquele ponto.
É como um checkpoint.
Ou, para o veterano do batch:
“O restart point da investigação.”
10. Stream Processing: investigando enquanto o crime acontece
O processamento em lote analisa fatos acumulados.
O stream processing analisa eventos enquanto eles chegam.
Exemplos:
Usuário iniciou episódio
Usuário pausou
Usuário retrocedeu
Usuário abandonou
Usuário terminou
Usuário iniciou o próximo episódio
Um pipeline em tempo real pode detectar comportamentos:
aumento repentino de audiência;
falhas em determinada região;
vídeos travando em um modelo específico de TV;
abandono acima do normal;
tentativa de fraude;
mudança de interesse;
tendência viral.
O sistema não precisa aguardar o batch da madrugada.
Pode reagir imediatamente.
Exemplo operacional
Se milhares de usuários começam a receber erro de reprodução em uma região:
PLAYBACK_ERROR aumentou 800%
REGIÃO = Sudeste
DISPOSITIVO = Smart TV modelo X
VERSÃO = 12.4
O pipeline pode gerar um alerta.
A equipe descobre que uma atualização específica introduziu o defeito.
No CSI New York, isso seria o equivalente a cruzar:
horário;
localização;
tipo de vítima;
arma;
padrão de ocorrência.
Na observabilidade, cruzamos:
timestamp;
região;
versão;
dispositivo;
endpoint;
código de erro;
duração;
dependência.
O método científico continua o mesmo.
11. Elasticsearch: a busca no catálogo de evidências
Quando o usuário digita uma palavra, o sistema precisa encontrar rapidamente títulos relacionados.
Uma consulta relacional simples com LIKE pode funcionar em bases pequenas:
SELECT TITULO
FROM CATALOGO
WHERE TITULO LIKE '%CONAN%';
Em grandes catálogos, com múltiplos idiomas, erros de digitação, sinônimos e relevância, é útil empregar um mecanismo especializado em pesquisa textual.
O Elasticsearch cria índices que facilitam buscas como:
palavras parciais;
termos semelhantes;
filtros;
relevância;
categorias;
idiomas;
combinações de campos.
Se o usuário digitar:
filme barbaro espada
O sistema pode retornar obras relacionadas mesmo que a frase completa não apareça em nenhum título.
Curiosidade forense
Um mecanismo de busca não apenas pergunta:
“Existe correspondência?”
Ele também pergunta:
“Qual correspondência é mais relevante?”
Essa ordenação pode considerar:
popularidade;
idioma;
histórico;
região;
perfil;
proximidade textual;
tendências.
Buscar não é apenas localizar.
É classificar evidências.
12. Spark, Hadoop e o laboratório de processamento pesado
Enquanto o streaming analisa dados em movimento, tecnologias de processamento distribuído podem analisar grandes volumes históricos.
O Apache Spark pode ser utilizado em tarefas como:
transformação de dados;
limpeza;
agregação;
análise;
treinamento de modelos;
consolidação de métricas;
processamento em larga escala.
Imagine bilhões de eventos de reprodução.
Uma análise pode perguntar:
“Quantos usuários abandonaram episódios entre os minutos 12 e 15 durante os últimos 90 dias?”
Outro estudo:
“Quais tipos de conteúdo são assistidos após documentários científicos?”
Essas perguntas podem exigir processamento de enormes conjuntos de dados.
No universo mainframe, o conceito lembra grandes workloads batch:
ENTRADA MASSIVA
↓
CLASSIFICAÇÃO
↓
AGREGAÇÃO
↓
CÁLCULO
↓
SAÍDA ANALÍTICA
A diferença está na forma como o processamento é distribuído entre diversos nós.
O programador COBOL não deve subestimar o batch
Existe uma narrativa equivocada segundo a qual batch é tecnologia ultrapassada.
Não é.
Spark, Hadoop e diversos pipelines modernos executam, em essência, formas sofisticadas de processamento em lote e paralelismo distribuído.
O batch não morreu.
Ele trocou o JCL por YAML, JSON, Python e interfaces web, mas continua acordando de madrugada para processar milhões de registros.
Esse é um dos easter eggs do mundo moderno.
13. Amazon S3 e armazenamento de objetos
O Amazon S3 é um serviço de armazenamento de objetos.
Ele pode armazenar:
arquivos;
imagens;
dados de processamento;
logs;
backups;
artefatos;
conteúdo multimídia;
resultados analíticos.
É importante não imaginar um “disco C:” gigantesco.
O S3 organiza dados como objetos identificados por chaves.
Exemplo conceitual:
bucket: catalog-assets
key: posters/8732451/pt-BR/main.jpg
O objeto possui:
conteúdo;
identificador;
metadados;
permissões;
políticas;
versionamento opcional.
Para o programador mainframe, podemos comparar conceitualmente o uso de diferentes classes de armazenamento, datasets, políticas de retenção e catálogos. Novamente, a implementação é distinta, mas o princípio de organizar, proteger e recuperar grandes volumes permanece familiar.
14. A entrega do vídeo e a CDN
Um dos pontos mais importantes é separar o backend de controle da entrega efetiva do conteúdo.
O backend decide:
quem pode assistir;
qual conteúdo;
qual perfil;
qual qualidade;
qual licença;
qual localização.
Mas enviar o vídeo para milhões de pessoas exige infraestrutura especializada.
A Netflix desenvolveu a Open Connect, sua própria rede de distribuição de conteúdo.
Servidores podem ser posicionados próximos aos provedores de internet, reduzindo a distância entre o conteúdo e o usuário.
Em vez de cada reprodução atravessar metade do planeta:
Usuário no Brasil
↓
Servidor distante
↓
Alta latência
O conteúdo pode ser entregue a partir de um ponto mais próximo:
Usuário
↓
Provedor local
↓
Servidor Open Connect
Isso reduz:
latência;
congestionamento;
custo de trânsito;
risco de interrupções;
tempo de inicialização.
Analogia da locadora
Imagine uma locadora central em Nova York responsável por atender o mundo inteiro.
Seria impossível entregar cada filme rapidamente.
Uma CDN funciona como uma rede de filiais que mantém cópias dos títulos mais procurados próximas aos clientes.
Quando surge uma estreia popular, o conteúdo pode ser posicionado previamente.
O arquivo chega antes do espectador.
A vítima ainda nem entrou na cena, mas a perícia já preparou o laboratório.
15. Tolerância a falhas: todos são suspeitos
Em ambientes tradicionais, muitas equipes tentam impedir qualquer falha.
Em arquiteturas distribuídas, parte-se de uma premissa diferente:
“Algum componente falhará.”
A pergunta deixa de ser:
“Como garantir que nada falhe?”
E passa a ser:
“Como continuar operando quando algo falhar?”
Isso exige padrões como:
timeout;
retry controlado;
circuit breaker;
fallback;
redundância;
isolamento;
filas;
replicação;
degradação graciosa.
Timeout
Uma chamada não pode esperar para sempre.
Serviço A chama Serviço B
Tempo máximo: 500 ms
Se B não responder, A precisa tomar uma decisão.
Retry
A pode tentar novamente.
Mas retries indiscriminados são perigosos.
Se um serviço já está sobrecarregado, milhares de tentativas extras podem piorar a situação.
É o equivalente a uma multidão tentando abrir a mesma porta emperrada.
Circuit Breaker
O circuit breaker interrompe temporariamente chamadas para um serviço com falhas.
Estados conceituais:
FECHADO
Chamadas permitidas
ABERTO
Chamadas bloqueadas
SEMIABERTO
Algumas chamadas de teste
Isso evita que toda a plataforma continue pressionando um componente doente.
Fallback
Se o serviço de recomendações estiver indisponível, a tela inicial não precisa ficar totalmente vazia.
Pode exibir:
Títulos populares
Continuar assistindo
Novidades
O sistema perde personalização, mas continua funcional.
Isso é degradação graciosa.
Uma falha parcial não precisa se transformar em blackout total.
16. Chaos Monkey: soltando o suspeito dentro do laboratório
Uma das iniciativas mais famosas associadas à engenharia da Netflix foi a prática de testar resiliência por meio de falhas provocadas.
O Chaos Monkey tornou-se símbolo dessa filosofia.
A ideia é desconfortável:
desligar componentes propositalmente para descobrir se o sistema suporta a perda.
Parece loucura.
Mas existe lógica.
Se a arquitetura afirma tolerar a perda de uma instância, é melhor comprovar isso de maneira controlada do que descobrir durante uma estreia global.
É semelhante a:
simular disaster recovery;
testar restauração de backup;
executar exercícios de contingência;
remover um nó de um cluster;
validar failover;
testar um plano de continuidade.
Easter egg CSI
O Chaos Monkey é como um investigador que entra na sala de evidências, apaga uma luz, remove uma câmera e pergunta:
“Vocês ainda conseguem resolver o caso?”
Se a resposta for não, o sistema não era resiliente.
Apenas parecia resiliente enquanto tudo funcionava.
17. Observabilidade: logs não bastam
Em um monólito, um log pode mostrar quase toda a sequência.
Em microserviços, uma única transação atravessa muitos componentes.
Precisamos de três pilares:
logs;
métricas;
traces.
Logs
Mostram eventos detalhados:
2026-07-26 02:17:31
PLAYBACK REQUEST RECEIVED
USER=U92837
TITLE=8732451
Métricas
Mostram comportamentos agregados:
requisições por segundo
latência média
percentil 95
taxa de erro
uso de CPU
memória
fila acumulada
Traces distribuídos
Acompanham uma requisição através de vários serviços.
Exemplo:
TRACE-ID: ABC-92871
Gateway 12 ms
Profile Service 18 ms
Catalog Service 25 ms
Rights Service 40 ms
Playback Service 85 ms
Agora sabemos onde o tempo foi gasto.
Sem trace, cada equipe diria:
“Meu serviço está normal.”
E o usuário continuaria esperando.
A correlação é a impressão digital
Todas as chamadas relacionadas à mesma transação devem carregar um identificador de correlação.
CORRELATION-ID = ABC-92871
Esse código funciona como o número do caso no CSI.
Sem ele, a equipe possui milhares de fragmentos, mas não consegue provar quais pertencem à mesma ocorrência.
18. Segurança: ninguém entra na cena sem credencial
A arquitetura precisa proteger:
contas;
dados pessoais;
pagamentos;
conteúdo;
licenças;
APIs;
infraestrutura;
segredos;
chaves;
tokens.
A autenticação responde:
“Quem é você?”
A autorização responde:
“O que você pode fazer?”
Um usuário autenticado pode assistir a determinados conteúdos, mas não pode:
alterar o catálogo;
consultar dados de outros assinantes;
chamar APIs administrativas;
acessar segredos;
modificar regras de distribuição.
No mundo mainframe, essa mentalidade é profundamente familiar.
O RACF, por exemplo, trabalha com identidades, recursos, perfis e permissões.
Em ambientes distribuídos, a segurança pode envolver:
IAM;
tokens;
OAuth;
certificados;
TLS;
roles;
políticas;
secrets managers;
controle de rede;
auditoria.
A regra central permanece:
conceder apenas o acesso necessário.
O nome moderno é “princípio do menor privilégio”.
O mainframe já conhecia essa disciplina antes de ela virar slide de conferência.
19. Passo a passo de uma reprodução
Vamos reconstruir o caso completo.
Passo 1 — O usuário abre o aplicativo
O cliente carrega configurações e estabelece uma conexão segura.
Passo 2 — A requisição chega ao balanceador
O tráfego é direcionado para uma instância saudável do Gateway.
Passo 3 — O Gateway valida a chamada
Ele verifica token, rota, limite e versão da API.
Passo 4 — O perfil é consultado
O serviço de perfil identifica preferências, idioma e classificação.
Passo 5 — O catálogo é analisado
O sistema verifica se o título existe e está disponível naquela região.
Passo 6 — Direitos são validados
Nem todo conteúdo pode ser exibido em todos os países ou períodos.
Passo 7 — A sessão de reprodução é criada
O backend define parâmetros de streaming, dispositivo e qualidade.
Passo 8 — O conteúdo é localizado
O sistema identifica o ponto de distribuição adequado.
Passo 9 — O cliente inicia a reprodução
O vídeo começa a ser entregue adaptativamente.
Passo 10 — Eventos são publicados
PLAYBACK_STARTED
Passo 11 — Consumidores processam o evento
Histórico, analytics, recomendações e monitoramento reagem.
Passo 12 — Métricas são acompanhadas
A plataforma mede travamentos, bitrate, buffering e abandono.
Passo 13 — A qualidade é ajustada
Se a conexão piorar, a resolução pode cair.
Se melhorar, pode subir novamente.
Passo 14 — A sessão termina
O ponto de parada é salvo e um evento final pode ser publicado.
Tudo isso nasce de um botão.
20. O que o programador COBOL deve estudar primeiro
Não tente aprender toda a arquitetura de uma vez.
Siga uma sequência.
1. HTTP e APIs REST
Aprenda:
GET;
POST;
PUT;
DELETE;
headers;
status codes;
JSON;
autenticação.
2. Comunicação síncrona e assíncrona
Entenda a diferença entre:
esperar a resposta
e:
publicar mensagem e continuar
3. Filas e eventos
Compare conceitos do MQ com Kafka, sem assumir que são idênticos.
4. Cache
Estude:
hit;
miss;
TTL;
invalidação;
consistência.
5. Escalabilidade
Aprenda a diferença entre:
escala vertical;
escala horizontal.
Escala vertical:
máquina maior
Escala horizontal:
mais máquinas
6. Observabilidade
Aprenda a interpretar:
logs;
métricas;
traces;
dashboards;
alertas.
7. Resiliência
Estude:
timeout;
retry;
circuit breaker;
fallback;
bulkhead.
8. Containers e orquestração
Depois dos fundamentos, avance para Docker e Kubernetes.
Não comece pelo Kubernetes sem entender a aplicação.
Isso seria como estudar JES2 antes de compreender o que é um JOB.
21. Lições que o mundo distribuído pode aprender com o mainframe
A indústria gosta de apresentar microserviços como uma revolução completa.
Mas vários princípios fundamentais já existiam em ambientes corporativos muito antes:
processamento transacional;
controle de carga;
alta disponibilidade;
segurança centralizada;
recuperação;
auditoria;
mensageria;
monitoramento;
isolamento;
governança;
capacidade de processamento massivo.
O mainframe ensina disciplina.
O mundo distribuído ensina flexibilidade e descentralização.
As melhores arquiteturas aprendem com ambos.
Um profissional COBOL não deve olhar para a Netflix e pensar:
“Tudo que aprendi ficou obsoleto.”
Deve pensar:
“Muitos problemas são conhecidos. O que mudou foi a forma de distribuí-los e tratá-los.”
Um ABEND em um programa batch costuma deixar evidências concentradas:
código;
dump;
joblog;
step;
dataset;
horário.
Uma falha distribuída pode deixar fragmentos em:
15 serviços;
8 logs;
3 regiões;
2 filas;
1 cache;
milhares de traces.
A habilidade de investigação torna-se ainda mais importante.
22. Curiosidades encontradas na sala de evidências
Curiosidade 1 — Microserviço não significa programa minúsculo
O tamanho deve refletir uma responsabilidade coerente.
Dividir demais produz “nano-serviços” que aumentam o tráfego e a complexidade.
Curiosidade 2 — Nem tudo precisa ser em tempo real
Muitos relatórios, consolidações e treinamentos de modelos podem ser batch.
Curiosidade 3 — O banco não deve ser tratado como fila
Usar uma tabela para simular mensageria pode funcionar em pequena escala, mas costuma criar bloqueios, consultas repetitivas e problemas operacionais.
Curiosidade 4 — Retry pode duplicar uma transação
Se o cliente envia uma cobrança, recebe timeout e tenta novamente, a primeira tentativa pode ter sido concluída.
Por isso, operações importantes precisam considerar idempotência.
Curiosidade 5 — Idempotência é o antídoto contra o duplo disparo
Uma mesma requisição repetida deve produzir um resultado controlado.
Exemplo:
IDEMPOTENCY-KEY: PAY-20260726-92871
Se a requisição for recebida novamente, o sistema reconhece que já a processou.
Curiosidade 6 — “Eventual consistency” não significa desorganização
Significa que diferentes partes podem levar algum tempo para convergir ao mesmo estado.
Mas esse comportamento precisa ser conhecido, medido e aceito pelo negócio.
Curiosidade 7 — Um sistema pode estar funcionando e ainda assim estar doente
A CPU pode estar normal, mas a latência aumentando.
Os servidores podem estar ativos, mas os caches com baixa taxa de acerto.
As APIs podem responder, mas os eventos podem estar acumulando.
Saúde não é apenas estar ligado.
Conclusão — O caso nunca foi apenas sobre streaming
No final da madrugada, o laboratório havia reconstruído o caminho da requisição.
O atraso não estava no vídeo.
Também não estava no banco.
A investigação encontrou uma cadeia inesperada:
o cliente iniciou a chamada;
o Gateway encaminhou corretamente;
o serviço de perfil respondeu;
o serviço de recomendação chamou uma dependência lenta;
a dependência não possuía timeout adequado;
threads começaram a se acumular;
o balanceador continuou enviando tráfego;
a latência contaminou outras chamadas;
o sistema não caiu;
mas ficou progressivamente mais lento.
O culpado não era um servidor quebrado.
Era uma espera sem limite.
O investigador fechou o relatório.
O programador COBOL olhou novamente para o diagrama.
Agora ele já não via apenas caixas coloridas e setas.
Via:
unidades de trabalho;
pontos de sincronização;
recursos compartilhados;
filas;
gargalos;
contratos;
estados;
dependências;
riscos;
evidências.
A arquitetura da Netflix não é importante apenas porque suporta vídeos.
Ela é importante porque demonstra como sistemas modernos podem ser construídos para operar em escala gigantesca, aceitando que máquinas falham, redes atrasam, serviços desaparecem e usuários continuam exigindo respostas imediatas.
Para o programador COBOL iniciante, a maior lição não é aprender nomes sofisticados.
Não é decorar Kafka, Spark, Elasticsearch ou API Gateway.
A verdadeira lição é compreender o fluxo.
Todo sistema recebe algo, valida, processa, consulta, decide, registra e responde.
O mainframe faz isso.
Os microserviços fazem isso.
A diferença está na distribuição das responsabilidades e na quantidade de fronteiras que a transação precisa atravessar.
No mainframe, muitas vezes entramos em um prédio fortificado.
Na arquitetura distribuída, atravessamos uma cidade inteira.
E em uma cidade com milhares de serviços, milhões de mensagens e bilhões de eventos, toda chamada deixa uma impressão digital.
Basta saber onde procurar.
No monitor do laboratório, uma nova ocorrência apareceu:
CASE NY-2026-0726
EVENT:
PLAYBACK_STARTED
STATUS:
PROCESSING
CORRELATION-ID:
BELLACOSA-MAINFRAME-001
O investigador pegou a caneca de café.
O programador abriu o terminal.
Em algum ponto da arquitetura, outra evidência acabava de ser produzida.
E o caso estava apenas começando.
BellacosaFlix Mainframe Developer Collection
Bootcamp DIO · Projeto Front-end
LusoFlix sem Mistérios para Programadores Web
Uma investigação completa sobre HTML, CSS e JavaScript, mostrando como um exercício inspirado na Netflix se transformou em um portal audiovisual de viagens, histórias, castelos e memórias de Portugal.
O que você encontrará nesta investigação
Os principais elementos técnicos analisados no projeto LusoFlix, organizados como uma coleção de episódios para estudantes de desenvolvimento web.
HTML como DATA DIVISION
Elementos semânticos, títulos, navegação, seções, artigos, links, imagens e a organização lógica da página.
CSS e identidade visual
Variáveis CSS, Flexbox, responsividade, gradientes, cores escuras, botões e aparência inspirada em streaming.
JavaScript e carrosséis
Scripts, bibliotecas externas, navegação horizontal, eventos e recursos capazes de tornar a página dinâmica.
Memórias de Portugal
Lisboa, Setúbal, castelos, monumentos, igrejas, gastronomia, praias, rios, turismo e vídeos do YouTube.
Artigo completo incorporado
Leia o conteúdo dentro desta página ou utilize o botão de acesso direto caso o navegador bloqueie a incorporação.
Bootcamp DIO Projeto LusoFlix: Programadores Front-end em HTML, CSS e JavaScript
BlogspotLusoFlix: desenvolvimento web com identidade própria
O LusoFlix nasceu como um projeto de desenvolvimento front-end realizado durante um Bootcamp da DIO. A proposta inicial era recriar uma interface inspirada na página principal da Netflix utilizando HTML, CSS e JavaScript.
Entretanto, o projeto ultrapassou a condição de simples clone. Em vez de reproduzir apenas uma coleção genérica de filmes e séries, o desenvolvedor criou um catálogo audiovisual dedicado a Portugal, reunindo vídeos sobre cidades, turismo, monumentos, história, castelos, praias, igrejas, gastronomia e experiências de viagem.
HTML semântico e organização do conteúdo
O HTML fornece a estrutura lógica da aplicação. Elementos como cabeçalho, navegação, seções, títulos, parágrafos, imagens, botões e links ajudam o navegador a compreender a hierarquia do conteúdo.
Uma estrutura semântica também favorece leitores de tela, tecnologias assistivas e mecanismos de busca, porque descreve a função de cada parte da página de maneira mais clara.
CSS, responsividade e experiência visual
O CSS é responsável pelo visual escuro, pelos destaques vermelhos, pela organização horizontal dos elementos, pelos espaçamentos e pelo comportamento responsivo. Recursos como Flexbox, variáveis CSS, gradientes, transições e media queries permitem adaptar a experiência a computadores, tablets e smartphones.
JavaScript e comportamento dinâmico
O JavaScript permite adicionar interatividade ao projeto. Carrosséis, eventos de clique, filtros, pesquisas, janelas modais e carregamento dinâmico de informações são exemplos de funcionalidades que podem ampliar uma página de catálogo.
Publicação e aprendizagem prática
O projeto demonstra como um exercício acadêmico pode se transformar em um produto pessoal. Ao associar programação, conteúdo autoral e memórias de viagem, o desenvolvedor deixa de apenas reproduzir uma interface e começa a construir uma experiência com identidade própria.
Leia a investigação completa no artigo Bootcamp DIO Projeto LusoFlix: Programadores Front-end em HTML, CSS e JavaScript .
- LusoFlix
- HTML5
- CSS3
- JavaScript
- Bootcamp DIO
- Desenvolvimento Front-end
- Clone Netflix
- GitHub Pages
- Web Design
- Portugal
- Programação Web
- Bellacosa Mainframe
