Zalando moved ad-event processing to Flink — what it means for the grind

Zalando’s engineering team posted that they migrated their ad-event processing pipeline to Apache Flink. The move was driven by a need to handle higher throughput, lower latency, and more reliable stateful processing across their ad infrastructure.

The old system relied on batch-oriented processing that introduced delays. Events from ad clicks, impressions, and conversions were queued, processed in windows, and then fed into downstream models. That worked when traffic was predictable. It didn’t scale cleanly when ad volume spiked during major sales or holiday seasons.

Flink gave them a streaming-first architecture. Events are processed in real time, with exactly-once semantics, checkpointed state, and horizontal scaling built in. The team noted that Flink’s state management — backed by RocksDB — helped them keep large key-value stores in memory without the overhead of external databases.

There was a migration cost. The team had to rewrite event schemas, restructure how they handled late events, and rebuild their monitoring stack around Flink’s metrics API. Some pipelines that ran in hours now run in seconds. Others that crashed under load now recover automatically after failures.

The engineering post doesn’t mention ad-targeting accuracy improvements directly, but the implication is clear: faster data means faster feedback loops for ad models, which means better ad delivery, which means better ROI for advertisers. That’s the chain.

Zalando’s move mirrors what many mid-to-large e-commerce companies are doing — shifting from batch to real-time event processing as ad tech becomes more dynamic and more expensive. When every millisecond of latency costs money, the pipeline matters.

Why this matters for us: When big platforms optimize their ad pipelines, the cost of running ads goes down, which changes what small sellers and community vendors can afford to push — and who gets seen when people scroll.