Zalando migra processamento de eventos de anúncio para Apache Flink, otimizando performance e custos
Aprofundamento CEVIU
Aprofundamento
A migração da Zalando para o Apache Flink em seu processamento de eventos de anúncio marca uma evolução importante na arquitetura de dados da empresa. O sistema anterior, uma aplicação Java distribuída com mais de sete anos, consumia streams Kinesis e Nakadi, armazenando eventos de lance em cache na memória. A principal limitação era a perda de estado em cada deploy ou rescale, forçando um superprovisionamento de pods para evitar a reescalada e a perda de dados, o que elevava custos e limitava a flexibilidade.
A nova solução, baseada em Flink, utiliza um backend de estado RocksDB com checkpoints incrementais de três minutos. Isso garante a persistência e recuperação do estado, permitindo autoscaling seguro sem perda de eventos. A equipe implementou uma KeyedCoProcessFunction personalizada para otimizar a lógica de matching de eventos, superando as ineficiências do IntervalJoin padrão do Flink, que gerava sobrecarga excessiva de I/O em RocksDB. Essa abordagem personalizada, aliada a ajustes finos nas configurações do RocksDB e a uma infraestrutura Kubernetes bem ajustada, foi crucial para o ganho de eficiência e a estabilização do estado.
O que mudou
A Zalando já havia demonstrado seu domínio em otimizar o Flink. A matéria de 6 de março de 2026, do CEVIU News, mostrou a empresa reduzindo em 75% o estado de suas aplicações, trocando a Table API por soluções customizadas via DataStream API. Essa experiência prévia, focada na otimização de joins e redução de estado, pavimentou o caminho para a decisão atual. Agora, a Zalando aplica esse conhecimento no DataStream API para um caso de uso crítico, migrando um sistema legado inteiro e comprovando a eficácia das otimizações. O Flink, antes em fase de 'TRIAL' no Tech Radar interno, agora é considerado 'ADOPT', refletindo a maturidade e a confiança da empresa na tecnologia.
Por que isso importa
Esta migração da Zalando demonstra como a modernização de pipelines de dados em tempo real pode gerar impactos financeiros e operacionais significativos. A redução de mais da metade nos custos diários de EC2, caindo de aproximadamente 80€ para 30€, é um exemplo claro de otimização de infraestrutura. Além disso, a melhoria de 0,5% na taxa de matching de eventos se traduz em maior faturamento e precisão para anunciantes. Para o mercado, o caso da Zalando serve como um blueprint, mostrando a importância da personalização de implementações de streaming, como a KeyedCoProcessFunction e o ajuste fino de RocksDB, para extrair o máximo desempenho e eficiência de plataformas como o Apache Flink em ambientes de alta demanda.
Linha do tempo
Zalando corta 75% do estado do Flink abandonando Table API.
Zalando migra processamento de eventos de anúncio para Apache Flink, otimizando performance e custos.
Perguntas frequentes
O que motivou a Zalando a migrar seu sistema de processamento de eventos de anúncio?
O sistema antigo, com mais de sete anos, era uma aplicação Java distribuída com limitações. Ele perdia o estado em cada deploy ou rescale, o que exigia o superprovisionamento de servidores e resultava em custos elevados. A falta de resiliência e a incapacidade de escalar de forma eficiente eram os principais motivadores.
Quais foram os principais ganhos da Zalando ao adotar o Apache Flink?
A migração resultou em ganhos significativos. Os custos diários de EC2 foram reduzidos em mais da metade, caindo de cerca de 80 euros para 30 euros. A taxa de matching de eventos melhorou em 0,5%, e a capacidade de realizar autoscaling seguro, sem perda de estado, trouxe mais flexibilidade operacional.
Como a Zalando garantiu que a migração para o Flink fosse bem-sucedida e sem interrupções?
A Zalando utilizou uma estratégia de 'pipeline sombra', rodando o novo sistema Flink em paralelo com o antigo por quatro semanas. Isso permitiu comparar a taxa de sucesso de enriquecimento de eventos, a correção dos resultados e a latência de processamento sem impacto nos usuários. Após validar a estabilidade das métricas, um teste A/B de uma semana confirmou a equivalência antes da transição completa.
Quais desafios técnicos a equipe da Zalando enfrentou com o Flink e como os superou?
Inicialmente, a equipe encontrou problemas de desempenho com o IntervalJoin padrão do Flink, devido a operações de busca ('seek') ineficientes no RocksDB. A solução foi implementar uma KeyedCoProcessFunction personalizada, que otimizou a lógica de matching e o gerenciamento de estado. Ajustes finos nas configurações do RocksDB e na infraestrutura Kubernetes também foram cruciais para a estabilidade e eficiência.
Fontes
- engineering.zalando.comfonte original
- Categoria
- CEVIU Dados
- Publicado
- 27 de julho de 2026
- Editoria
- CEVIU Dados

