How Delivery Hero Revolutionized Ad Measurement Through Real-Time Streaming Architecture
In the high-stakes world of digital advertising, the gap between a consumer’s click and the subsequent billing of a vendor is a critical performance metric. Delivery Hero, the Berlin-based global delivery giant operating in 65 countries, recently concluded a major infrastructure transformation that replaced its legacy hourly batch-processing ad measurement system with a state-of-the-art, real-time pipeline powered by Amazon Managed Service for Apache Flink. This transition, which involved shifting from a 61-minute latency to a near-instantaneous 1.2-second response time, underscores a broader industry shift toward streaming architectures as a prerequisite for competitive advertising revenue, which for Delivery Hero reached approximately EUR 1.5 billion in 2025.
The challenge of ad measurement at scale is immense. For a platform managing millions of daily orders across Asia, Europe, Latin America, the Middle East, and North Africa, the system must perform two disparate functions simultaneously: it must provide precise, auditable data for billing vendors, and it must offer sub-second freshness to inform automated ad-serving decisions.
The Structural Deficiencies of the Legacy System
Prior to the migration, Delivery Hero relied on a batch-oriented architecture that became increasingly untenable as the platform scaled to process billions of events daily. Engineering teams identified five core technical bottlenecks that hampered performance and data integrity.
First, the legacy system suffered from a lack of event-time semantics. Because incoming events often lacked standardized timestamps, the system processed data based on the time of arrival rather than the time of occurrence. This led to significant skew during periods of network congestion or ingestion lag, undermining the accuracy of critical metrics like Return on Ad Spend (ROAS). Because the pipeline operated in hourly batches, the "event-to-insight" gap was consistently over an hour, preventing the ad server from reacting to real-time budget depletion or sudden traffic spikes.
Second, the system relied on synchronous API calls for data enrichment. Each ad event required fetching campaign metadata and product information in real-time. During peak traffic—such as during flash sales—this created a cascading failure effect. If the enrichment service slowed down, it throttled the entire ingestion pipeline, creating a single point of failure that impacted billing, ad serving, and reporting simultaneously.
Third, the storage architecture was fundamentally ill-suited for the workload. The platform utilized a NoSQL document database designed for infrequent storage and retrieval, rather than the high-velocity, continuous mutation requirements of an ad-measurement stream. This led to significant read/write amplification, where simple updates forced the system to perform unnecessary document reads and index refreshes, driving up costs and latency in lockstep with traffic volume.
Fourth, the legacy system lacked robust replayability. Recovering from corrupted data or system bugs was a manual, fragmented process requiring custom CLI scripts, Google Cloud BigQuery adjustments, and separate Airflow jobs. This lack of a unified recovery mechanism meant that many event types had no path for correction, forcing engineering teams to manually patch data post-facto.
Finally, the best-effort, synchronous nature of enrichment resulted in data quality degradation. Events that failed lookup processes were often written with blank fields, leading to significant gaps in session context—up to 40% of sessions lacked proper attribution, and 91% of impressions arrived without reliable timestamps.
The Path to Real-Time: A Chronology of the Transformation
The decision to migrate to a streaming architecture was driven by the necessity for fault tolerance and stateful processing. The engineering team, led by a collaborative group from Delivery Hero including Kirill Tishenkov, Alexandru Pisarenco, Upendra Kambhampati, and Sabariesh Ganesan, established three non-negotiable requirements: near-zero data loss, multi-day stateful interaction history, and fully managed infrastructure to reduce operational overhead.
The team selected Apache Flink as the core processing engine. Flink’s native ability to handle event-time watermarks allowed the system to correctly order out-of-sequence events. By leveraging the RocksDB state backend, the system could store massive volumes of interaction history on local disks without overloading the Java Virtual Machine (JVM) heap, providing the memory efficiency required for high-throughput stream processing.
The implementation phase moved through several distinct stages:
- Ingestion Layer: The team utilized Amazon Kinesis Data Streams as the upstream event bus, opting for it over Kafka for its cost-efficiency and tighter integration with the AWS ecosystem.
- Buffer and Forward: Amazon EventBridge Pipes were deployed to connect Simple Queue Service (SQS) buffers to the stream, significantly accelerating the Minimum Viable Product (MVP) phase by reducing the need for custom integration code.
- Decryption and Deduplication: Upon entering the Flink pipeline, events are decrypted using keys retrieved from AWS Secrets Manager. The pipeline then performs deduplication to ensure that even if events are retried at the transport layer, they are processed exactly once.
- Stateful Enrichment: Using the Flink Async I/O API, the system queries Amazon DynamoDB to attach business context to events. By performing this asynchronously, the pipeline avoids blocking, ensuring that enrichment does not gate ingestion.
- Output and Persistence: Granular event logs are stored in Avro format on Amazon S3, while aggregated metrics are pushed to a dedicated reporting database. Billing events are sent to Apache Kafka to trigger downstream ad server actions.
Data Fidelity and Economic Impact
The results of the migration have been substantial, characterized by both technical performance gains and significant fiscal savings. Perhaps the most notable improvement is the reduction in latency. By moving from hourly windows to real-time processing, the average time between event publication and recording dropped from 61 minutes to just 1.2 seconds. This shift enables the ad server to make "just-in-time" decisions, optimizing budget allocation with a precision that was previously impossible.
Operational costs also saw a marked decline. The migration resulted in a 57% reduction in monthly infrastructure costs. This was achieved by moving away from the expensive, write-heavy NoSQL database model to a leaner, streaming-first architecture.
The data quality improvements were equally impressive, effectively eliminating the systemic gaps identified in the legacy system. The "missing session" rate dropped from 30–40% to 0%, and the missing timestamp rate fell from 91% to 0.2%. These improvements have had a direct impact on the efficacy of the company’s machine learning models. By providing models with complete, session-scoped features, the team has enhanced the accuracy of campaign ranking, conversion-rate estimation, and anomaly detection.
Broader Implications for the Advertising Industry
The transformation at Delivery Hero serves as a blueprint for other global advertising platforms. The success of this architecture suggests that the traditional divide between batch reporting and real-time ad serving is collapsing. Companies that continue to rely on legacy "reconciliation-after-the-fact" models are likely to find themselves at a disadvantage compared to competitors capable of adjusting ad budgets and targeting strategies in seconds rather than hours.
Furthermore, the integration of streaming data as a foundation for AI-driven use cases represents the next frontier. With a robust real-time pipeline in place, Delivery Hero is now exploring the use of live interaction streams to power personalization ranking models and grounded Large Language Model (LLM) recommendations. These initiatives were deemed impractical with the previous batch-oriented infrastructure.
Industry analysts note that this architectural shift marks a maturation in how digital platforms handle "data as a product." By treating past data as a first-class, replayable input rather than a "frozen artifact," Delivery Hero has created a system that is not only more resilient to current traffic loads but also significantly more adaptable to future technological requirements.
In summary, the transition from hourly batch processing to a real-time, stateful streaming model on AWS has allowed Delivery Hero to solve one of the most difficult challenges in advertising: reconciling the need for absolute billing accuracy with the requirement for instantaneous system responsiveness. As the digital advertising market continues to prioritize real-time signals, this approach provides a scalable and cost-effective standard for global platforms to follow.
