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

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.

HTML5
CSS3
JavaScript
Bootcamp DIO
GitHub Pages
Portugal
Front-end

▶ Ler agora ⓘ Abrir original

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.

Estrutura

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.

Interface

CSS e identidade visual

Variáveis CSS, Flexbox, responsividade, gradientes, cores escuras, botões e aparência inspirada em streaming.

Interatividade

JavaScript e carrosséis

Scripts, bibliotecas externas, navegação horizontal, eventos e recursos capazes de tornar a página dinâmica.

Conteúdo

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

Blogspot

LusoFlix: 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

Translate

quarta-feira, 5 de junho de 2024