Arquitetura Lambda: quando batch e streaming trabalham juntos

No universo da Engenharia de Dados, uma das decisões mais comuns envolve escolher como os dados serão processados.

Em alguns cenários, processar dados em lote (batch) é suficiente.

Em outros, esperar minutos ou horas simplesmente não é aceitável.

Sistemas modernos frequentemente exigem respostas quase instantâneas.

Pense em:

Detecção de fraude bancária
Recomendação em e-commerce
Monitoramento de sensores IoT
Dashboards operacionais em tempo real

Nesses casos, latência importa.

Mas existe um problema.

Processamento em tempo real é rápido, porém nem sempre oferece a mesma robustez analítica de um processamento batch completo.

Já o batch entrega precisão e capacidade de reprocessamento histórico, mas possui maior latência.

Foi exatamente para resolver esse conflito que surgiu a Arquitetura Lambda.

Seu objetivo é combinar o melhor dos dois mundos:

Velocidade do streaming
Precisão do batch

O conceito da Arquitetura Lambda

A Arquitetura Lambda foi proposta por Nathan Marz, um dos nomes mais conhecidos em sistemas distribuídos.

A ideia central é relativamente simples:

Em vez de escolher entre batch ou real-time, usamos ambos em paralelo.

Isso permite que o sistema entregue resultados imediatos enquanto mantém uma camada de reprocessamento confiável.

Para isso, a arquitetura é dividida em três camadas principais.

Batch Layer

A Batch Layer é responsável por armazenar o dataset completo, também chamado de master dataset.

Essa camada mantém todos os dados brutos e históricos.

Periodicamente, ela recalcula visões completas a partir desse histórico.

Funções principais:

Armazenamento histórico
Reprocessamento completo
Correção de inconsistências
Cálculos analíticos pesados

Um ponto importante:

Se houver erro em alguma lógica de transformação, essa camada permite recalcular tudo novamente desde a origem.

Isso traz confiabilidade.

Tecnologias comuns:

Apache Spark
Apache Hadoop
Databricks

Speed Layer

A Speed Layer existe para reduzir latência.

Em vez de esperar o batch rodar, ela processa os eventos assim que chegam.

Cada clique, compra, transação ou evento pode ser analisado imediatamente.

Funções principais:

Processamento contínuo
Respostas instantâneas
Alertas em tempo real
Detecção de anomalias

Essa camada geralmente trabalha com streams infinitos de dados.

Aqui, baixa latência é prioridade absoluta.

Tecnologias comuns:

Apache Kafka
Apache Flink
Spark Streaming

Serving Layer

A terceira camada é a Serving Layer.

Seu papel é disponibilizar os resultados processados para consumo.

Ou seja:

Tudo o que foi processado nas camadas anteriores precisa ficar acessível para aplicações.

Exemplos de consumo:

Dashboards
APIs
Sistemas de analytics
Modelos de Machine Learning

Tecnologias comuns:

Elasticsearch
Apache Druid
Databricks

Fluxo da Arquitetura

O fluxo normalmente segue este padrão:

Data Sources → Batch + Speed → Serving → Consumers

Parece simples visualmente.

Mas na prática, existe muita engenharia envolvida para manter consistência entre as camadas.

Exemplo prático: sistema de pagamentos

Imagine uma fintech processando milhões de transações.

Quando uma compra acontece:

A Speed Layer analisa a transação em segundos para detectar fraude.

Caso encontre comportamento suspeito, bloqueia imediatamente.

Enquanto isso, a Batch Layer roda modelos mais complexos usando todo o histórico.

Ela recalcula scores, padrões e perfis de risco com maior precisão.

Depois, a Serving Layer entrega esses insights para dashboards, APIs e times de negócio.

Resultado:

O sistema consegue reagir rápido sem abrir mão da confiabilidade analítica.

Vantagens

A Arquitetura Lambda ganhou popularidade por resolver problemas complexos em escala.

Principais vantagens:

Alta escalabilidade
Baixa latência
Reprocessamento histórico
Tolerância a falhas
Melhor precisão analítica

Desafios

Porém, ela não é perfeita.

Seu maior problema está na complexidade.

Em muitos casos, você precisa manter a mesma lógica em dois mundos diferentes:

Um pipeline batch e outro streaming.

Isso significa:

Mais código
Mais infraestrutura
Mais custo operacional
Mais manutenção

Esse é o principal motivo pelo qual arquiteturas mais recentes ganharam espaço.

Lambda vs Kappa

Com engines modernas como Apache Flink, muitas empresas passaram a adotar a Kappa Architecture.

A proposta da Kappa é simplificar.

Em vez de manter batch + streaming, tudo passa a ser processado como stream.

Menos camadas. Menos duplicidade. Menor complexidade.

Mesmo assim, entender Lambda continua extremamente importante.

Porque ela introduziu conceitos que ainda influenciam arquiteturas modernas.

Conclusão

A Arquitetura Lambda mostrou que sistemas de dados não precisam escolher entre velocidade e precisão.

Em muitos cenários, o melhor caminho é combinar ambos.

Mais do que uma arquitetura específica, Lambda representa uma forma de pensar sobre trade-offs em Engenharia de Dados.

E uma lição continua atual:

A melhor arquitetura raramente é a mais simples ou a mais complexa.

É a que resolve o problema certo com o nível adequado de complexidade.

E você?

Na sua visão, com a evolução de stream processing moderno, a Arquitetura Lambda ainda faz sentido... ou Kappa já se tornou o novo padrão?