Delivery Hero’s Flink Rebuild: From Hourly Measurement to Near Real Time

What happened

In a joint case study published on 24 September 2026, AWS and Delivery Hero described replacing an hourly advertising-measurement pipeline with a real-time pipeline built on Amazon Managed Service for Apache Flink.

Delivery Hero reports that the average gap between an event being published and recorded fell from 61 minutes to 1.2 seconds.

The company also reports that monthly operating costs decreased by approximately 57%. The architecture still batch-upserts reporting aggregates every five minutes, so the latency figure should not be read as a refresh guarantee for every downstream report.

These figures were reported by AWS and Delivery Hero. They have not been independently reproduced by DataStackSignals and should not be treated as universal performance expectations.

Why it matters

Advertising measurement has two difficult requirements:

• events must be fresh enough to influence advertising decisions;
• records must remain accurate enough to support charging and financial reporting.

The case challenges the assumption that real-time processing must always cost more than batch processing.

Repeatedly recomputing large batches can sometimes be more expensive than maintaining an efficient stateful streaming pipeline.

However, the result cannot be transferred directly to every workload. Event volume, state size, late-arriving data, recovery design and the cost structure of the previous system will influence the outcome.

Who it affects

Streaming architects, advertising and marketplace data teams, finance-data owners and organisations considering batch-to-streaming migration.

What to do next

Identify one batch pipeline where the value of the information decreases quickly as the data becomes older.

Before changing the architecture, establish a baseline covering:

• current processing cost;
• data freshness;
• reconciliation errors;
• support effort;
• retry behaviour;
• recovery time;
• business decisions affected by the delay.

A streaming replacement should then be tested for accuracy and recovery—not simply latency.

Signal Take

Real-time architecture is justified when faster data changes a decision, control or commercial outcome. Freshness alone is not a sufficient business case.

Scope and limitations

This analysis interprets the linked AWS material. Recommendations are editorial judgement, not tested implementation instructions. No independent product benchmark or deployment test was performed.