I spent close to two decades building distributed systems and streaming platforms before co-founding Factor House in 2019, including several years advising banks on Kafka and Cassandra deployments, and Booking.com is the fourth stop in a running project of reading how engineering teams actually operate Apache Flink day to day, after Netflix’s, Uber’s, and Lyft’s. This one has a thinner paper trail than any of the other three: four sourced pieces that name an author or a named conference speaker, all read directly, plus three vendor case-study pages I’m using only to corroborate scale figures Booking.com hasn’t published itself. Booking.com’s own engineering blog has no Flink-specific post at all, as far as I could find.
What makes it worth writing up anyway is that the story is genuinely narrow rather than thin from bad luck. Booking.com’s public account of Flink is scoped to a single internal platform, run by its Security Platform Services team, and that narrowness is exactly what let the two engineers who built it describe real operational detail: how a small platform team supported a fast-growing number of stateful jobs across several other teams without becoming the bottleneck itself. It is a smaller and more specific story than Netflix’s 30,000-job fleet or Uber’s SQL platform, but the underlying problem, upgrading many stateful Flink applications without a lengthy pipeline restart, is one that catches teams well before they reach Booking.com’s own scale.
Company overview
Booking.com is one of the world’s largest online travel agencies, connecting travelers with hotel, flight, rental car, and other accommodation listings globally. The only part of that business with a documented public Flink story is its Security Platform Services team, a group responsible for processing streaming security-related data for internal use, described by its own engineers as building a “security-as-a-service” platform for other Booking.com teams to use.
| Date | Milestone |
|---|---|
| Circa 2018 (approximate) | Booking.com’s Security Platform Services team begins building a Kafka, Flink, and Elasticsearch-based security platform |
| Aug 2022 | David Ponessa and Pedro Ceriotti present the platform’s Flink architecture as a keynote at Flink Forward San Francisco |
| Oct 2024 | Booking.com is featured as a Ververica customer at Flink Forward Berlin, discussing the platform’s scaling impact |
| 2025 | Booking.com is listed among the speakers for Flink Forward Barcelona |
Booking.com’s Flink use cases
Security-as-a-service: a shared platform for internal security teams
Booking.com’s Security Platform Services team chose Flink as the engine for all of its security data processing, then built an application framework on top of it so that other internal security teams could build their own pipelines without needing deep Flink expertise themselves. As David Ponessa and Pedro Ceriotti described in their Flink Forward San Francisco keynote, the platform is meant to abstract pipeline-building complexity behind a single, unified, extensible schema, and multiple internal security teams now build their own Flink-based pipelines on the shared platform rather than routing every new pipeline through one central team, a model Ververica’s own SIEM use-case page describes as running under segregation-of-duty principles with access control between tenants.
That is the only Flink use case at Booking.com with a verifiable, named source behind it. I came across a secondary reference to a separate Booking.com talk touching on fraud or transaction processing, but couldn’t get a working link to the original source to confirm what was actually said, so I’m leaving it out entirely rather than repeating an unconfirmed claim.
Scale and throughput
Booking.com’s most recent public mention of this platform came at Flink Forward Berlin 2024, where Siddhartha Choudhury, a Senior Product Manager at Booking.com, discussed the platform’s scaling impact as a Ververica customer highlight, without going into specific figures himself. The figures below come from Ververica’s own case study on the account instead.
- Flink job count: grew from roughly 10-20 jobs to more than 250, according to Ververica’s case study on the Booking.com account, a vendor-reported figure Booking.com itself has not published directly.
- Deployment and stateful-upgrade time: one copy of the same case study puts this at roughly 20 minutes down to 1-4 minutes per deployment, while the live version on Ververica’s own site describes the same change more loosely as “hours to a matter of minutes.” The two disagree on the specific before-state, so I’d treat the exact figures as vendor-reported context rather than an independently confirmed number.
- Not found: Booking.com has not published events-per-second, retention, or cluster-count figures for this platform.
I’d read the jump from a couple of dozen jobs to more than 250 as a proxy for how much the old, slower deployment and upgrade process was costing this specific team as more security use cases piled onto the platform, rather than as a general benchmark for how large a Flink platform “should” grow to.
Booking.com’s Flink architecture
Ververica Platform as the orchestration layer
Booking.com uses Ververica Platform to manage the lifecycle of its Flink applications: deployment, stateful upgrades, and multi-tenancy, according to Ververica’s case study and the SIEM use-case page describing the account.
A segregation-of-duties model for multi-tenant pipelines
Rather than one central team owning every security pipeline, the platform is built so that individual security teams can manage their own Flink applications under segregation-of-duty principles and access control, while the central Platform team maintains the overall solution instead of operating every pipeline itself.
The underlying stack: Kafka, Flink, and Elasticsearch
Per David Ponessa’s own speaker bio for the Flink Forward San Francisco 2022 keynote, the Security Platform is built on “Kafka, Flink and Elasticsearch.” No source found describes how this platform connects to Booking.com’s broader, non-security data infrastructure, or whether it runs on Kubernetes, YARN, or a standalone Flink deployment.
Special techniques
A unified pipeline abstraction framework
The Security Platform Services team built an application framework on top of Flink specifically to abstract the complexity of building a data processing pipeline behind a single, unified, extensible schema, so that a security team building a new use case works against that schema rather than against Flink’s own APIs directly. No source found goes into the framework’s internals, such as custom state backends or windowing strategies, beyond this framing.
Operating Flink at scale
Self-service within a shared platform
Multiple security teams operate independently on the same Flink platform under access control between tenants, which is the specific operational goal Booking.com’s own account credits Ververica Platform with enabling.
Stateful upgrades as a first-class operation
The case study frames stateful upgrade support, rather than a full pipeline restart and backfill, as a core requirement Booking.com selected Ververica Platform to meet, consistent with an environment where dozens of independently owned jobs need to keep running while any one of them changes.
I’ve watched more than one platform team default to “just restart the job” as their upgrade story because building real stateful-upgrade tooling is genuinely hard, and it tends to work fine right up until job count and tenant count both grow past what a restart-and-backfill cycle can tolerate. Closing that specific gap is a problem I spend a lot of my own working time on, which is part of why Booking.com’s account of it stood out to me.
Leaning on vendor expertise to cover the gap
Booking.com’s own account cites access to “Flink expert support with fast response times” as a stated benefit of the Ververica relationship, on top of the platform tooling itself.
Challenges and how they solved them
Scaling a growing set of pipelines without growing the platform team
As more internal security teams adopted the shared Flink platform, the Security Platform Services team needed each of those teams to be able to deploy and upgrade its own pipelines independently, without the central team becoming a bottleneck or having to operate every pipeline itself.
Problem: A small central Platform team could not keep operating every security team’s Flink pipeline by hand as the number of pipelines grew from roughly a dozen toward hundreds.
Root cause: Deployment and stateful upgrades were slow and centrally handled, so adding a new security use case meant more manual work for the same small team rather than self-service work by the team that owned the use case.
Solution: Booking.com adopted Ververica Platform so that each security team could manage its own Flink applications independently under a segregation-of-duties access model, while the central Platform team focused on maintaining the overall platform rather than every individual pipeline.
Outcome: Deployment and stateful-upgrade time dropped from a vendor-reported “hours” or “roughly 20 minutes” down to one to four minutes, and the platform grew to more than 250 jobs, per Ververica’s case study; Booking.com has not independently published these figures itself, so I’d treat them as directionally credible rather than confirmed.
Full tech stack
| Category | Tools | Notes |
|---|---|---|
| Stream processing | Apache Flink | Core engine for all security data processing on the platform |
| Orchestration | Ververica Platform | Manages deployment, stateful upgrades, and multi-tenancy for Flink applications |
| Messaging | Apache Kafka | Named as part of the Security Platform stack alongside Flink and Elasticsearch |
| Storage and search | Elasticsearch | Named as part of the same Security Platform stack |
Key contributors
| Name | Role | Contribution |
|---|---|---|
| David Ponessa | Site Reliability Engineer, Security Platform Services, Booking.com | Co-presented the Flink Forward San Francisco 2022 keynote on the Security Platform; per his speaker bio, spent roughly four years building it, focused on scalability and reliability design |
| Pedro Ceriotti | Site Reliability Engineer, Security Platform Services, Booking.com | Co-presented the same keynote; per his speaker bio, led adapting and implementing Ververica Platform into Booking.com’s environment |
| Siddhartha Choudhury | Senior Product Manager, Booking.com | Represented Booking.com at Flink Forward Berlin 2024 as a Ververica customer highlight, discussing the platform’s operational scaling impact |
Key takeaways for your own Flink implementation
These are the patterns from Booking.com’s account, and the gaps around it, that I’d point any team toward:
- Treat stateful upgrades as a first-class requirement, not an afterthought. Booking.com’s own stated motivation for adopting a management layer wasn’t job count on its own, but the operational cost of upgrading many stateful jobs without a lengthy restart, a problem worth planning for long before you reach Booking.com’s own scale.
- Real multi-tenancy lets one platform team support many teams. The segregation-of-duties model in Booking.com’s account let individual security teams manage their own Flink applications rather than routing every change through a central team, worth considering any time more than one team wants to build on a shared Flink platform.
- A narrow use case can still be worth writing up in detail. Booking.com’s public Flink story is scoped to one internal platform rather than company-wide streaming, and that narrow scope is what let its own engineers describe operational detail, deployment time, upgrade model, and vendor relationship, that a broader survey often skips.
- Treat vendor-reported scale figures as directional, not verified. Where Booking.com’s own account is silent on throughput and precise job-count figures, a vendor case study filled part of that gap; useful context, but worth flagging to your own team as unconfirmed rather than citing as a company disclosure.
I’ll keep working through the rest of the list and write up the next one as it’s ready.
Sources and further reading
Primary sources
- David Ponessa and Pedro Ceriotti, “Apache Flink as a security data processing engine at Booking.com,” Flink Forward San Francisco (keynote) - https://www.youtube.com/watch?v=-wSbb4JSuZU (2022)
- David Ponessa and Pedro Ceriotti, speaker bios, Flink Forward San Francisco 2022 - https://www.flink-forward.org/san-francisco-2022/speakers (2022)
- Ravit Jain, “Highlights from Flink Forward Berlin 2024,” The Ravit Show Newsletter - https://www.newsletter.theravitshow.com/p/highlights-from-flink-forward-berlin-2024 (2024)
- Siddhartha Choudhury, speaker listing, Flink Forward Barcelona 2025 - https://www.flink-forward.org/barcelona-2025/speakers (2025)
The scale figures cited above come from Ververica’s own case study on the Booking.com account, used here only as corroborating context since Booking.com hasn’t published these numbers itself: Ververica, “Booking.com case study” - https://www.ververica.com/case-study/booking (undated), a mirrored copy at https://www.scribd.com/document/709178433/Ververica-Case-Study-PDF-Booking-com (undated), and Ververica’s “Security information and event management” use-case page - https://www.ververica.com/use-case/security-information-and-event-management (undated). Each is flagged inline above where it’s used.
Enterprise tooling for Apache Flink
If your own team is weighing a similar move, from a handful of ad hoc Flink jobs into something a central platform team can support at scale without every consuming team needing deep Flink expertise, that’s exactly the operational picture my team and I build for at Factor House. It’s part of why an account like Booking.com’s is worth this much attention even with a thin public paper trail: Flex, our enterprise UI and API for Apache Flink, exists to make deployment, stateful upgrades, and multi-tenant governance manageable without building all of the tooling described above in-house.