# Booking.com Development - Medium Software engineering at Booking.com - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How We Built Automated Capacity Testing for Kafka Consumers DevFeed: [How We Built Automated Capacity Testing for Kafka Consumers]() Original publisher: [Read original article]() Author: Kaan Karakaya Published: 2026-09-14T09:46:34Z Content type: tutorial Language: en Sources: [Booking.com Development - Medium]() Topics: [Kafka](), [Testing](), [HTTP]() Tags: [automated](), [capacity](), [health-checks](), [kafka](), [load](), [load-balancer](), [parallelism](), [partition](), [recovery](), [scale](), [site-reliability-engineer](), [sre](), [testing]() ### AI overview This article describes Booking.com's extension of an existing capacity-testing platform for Kafka consumers. It explains how changing partition assignment can provide a controlled, measurable way to test consumer throughput and whether remaining consumers can absorb reassigned work after an instance or failure domain disappears. ### Source excerpt Photo by GuerrillaBuzz on Unsplash Kafka makes it easy to distribute work across consumer instances. It is much harder to prove, safely and repeatedly, how those instances behave when the distribution changes and one of them has to carry more than its usual share. For teams that run Kafka at scale, this is a practical reliability question: how much load can a consumer instance actually handle? We had automated capacity testing for HTTP services, but Kafka consumers were still tested with manual drills. Those drills could tell us something, but they were disruptive, difficult to reproduce, and risky precisely when the system was close to its limit. We wanted a controlled way to answer three questions: What is the maximum sustainable throughput of a consumer instance? If an instance or failure domain disappears, can the remaining consumers absorb the reassigned work? Are we overprovisioning resources because we do not know the real limit? The result was an extension to our capacity-testing platform that turns Kafka partition assignment into a safe, measurable load-control mechanism. Why HTTP capacity testing did not translate Our existing platform was designed for request-response services behind a load balancer. A scheduled test selects one instance, routes an increasing share of traffic to it, runs health checks after each step, and records the highest ratio the instance can sustain. After the test, traffic returns to its normal distribution and the result is reported to the service owner. Kafka has no equivalent traffic knob. Consumers pull records, and the unit of parallelism is the partition. Within a consumer group, each partition is owned by one consumer at a time. If a topic has 12 partitions and four equally loaded instances, each instance owns about three. When one instance disappears, a rebalance gives the survivors more partitions -- and the extra work arrives as a step change, not as a smooth increase from a load balancer. The key translation: for an HTTP ## Beyond the Dashboard: Accelerating Real-Time Intelligence in the Age of AI DevFeed: [Beyond the Dashboard: Accelerating Real-Time Intelligence in the Age of AI]() Original publisher: [Read original article]() Author: Kostiantyn Okhrimenko Published: 2026-08-27T11:15:58Z Content type: article Language: en Sources: [Booking.com Development - Medium]() Topics: [semantic-layer](), [genai](), [analytics stack](), [Large Language Model](), [Artificial Intelligence](), [data](), [dashboards](), [Query (disambiguation)]() Tags: [agent](), [ai](), [ai-tools](), [analytics-stack](), [bi-tools](), [dashboards](), [data](), [genai](), [real-time](), [self-service](), [self-serving-analytics](), [semantic-layer](), [sql]() ### AI overview The article examines how GenAI-driven natural-language interfaces can help stakeholders obtain trusted data answers without repeatedly interrupting data and engineering teams. It argues that a robust semantic layer is necessary to make self-service analytics reliable and precise. ### Source excerpt When an urgent request for a report or dashboard arrives, often just before an executive meeting, data and engineering teams must drop planned work to respond. One request may be reasonable, but repeated interruptions come at a cost: important work, such as scaling infrastructure, improving reliability, models optimization, gets pushed back, while quick, one-off dashboards become more technical debt to maintain. For managers and other decision-makers, the need is real: they require reliable data to make decisions quickly. But getting an answer often depends on someone who knows SQL, understands the data structure, and has time to help. When those people are already busy, the question waits, even when the answer is sitting in the data warehouse. By the time the report is ready, the decision window may have passed. This is not just a prioritization issue. We need a better way for people to get trusted answers quickly without constantly pulling teams away from building and improving the data platform. All of the above can be illustrated by the image: Image 1: Typical reporting circleWhat we will talk about The explosion of GenAI over the last few years has shifted the focus for the modern analytics stack. We are evolving beyond traditional Data Democratization, which often gave teams access to complex pre-AI tools without clear governance, toward natural language data interaction: asking questions in plain English -- Talk to your data concept. In the traditional stack, the "interface" to data was either a dashboard or a SQL editor. This created a high barrier to entry that caused the friction. By properly architecting and utilizing GenAI-driven tools, we can finally bridge the gap between intent and insight. Talk to your data is a self-serve ecosystem where any stakeholder can bypass the traditional ticketing queue and, instead of waiting for an engineer to interpret a requirement and translate it into a query, the user engages with a specialised agent. The challenge, h ## Kotlin Multiplatform in Production: Two Real-World Use Cases from Booking.com DevFeed: [Kotlin Multiplatform in Production: Two Real-World Use Cases from Booking.com]() Original publisher: [Read original article]() Author: Diego Gómez Olvera Published: 2026-06-05T15:09:18Z Content type: article Language: en Sources: [Booking.com Development - Medium]() Topics: [Kotlin Multiplatform](), [compose-multiplatform](), [experiments](), [A/B Testing](), [Android](), [iOS](), [Design system](), [Mobile](), [Development]() Tags: [a-b-testing](), [android](), [booking](), [bookingcom](), [compose](), [compose-multiplatform](), [concepts](), [consistency](), [data](), [development](), [engineering](), [experiment](), [experimentation](), [experiments](), [ios](), [java](), [jetpack-compose](), [kotlin](), [kotlin-multiplatform](), [mobile](), [multiplatform](), [objective-c]() ### AI overview This article describes two Booking.com engineering use cases for Kotlin Multiplatform and Compose Multiplatform: a shared experimentation library for consistent experiment assignments across Android and iOS, and hosting an Android design system in a web browser. ### Source excerpt Introduction For the majority of Booking.com travelers, mobile is the primary channel for researching, planning, and booking trips. Recent data shows that over 80% of travelers rely on a mobile app during the research phase, with more than half of all bookings occurring on mobile devices. Consequently, the Android and iOS platforms are critical to the company's product strategy; engineering choices made here have significant repercussions for the entire organisation. To maintain agility at this scale, two elements must function in unison: Strict decision validation: At any time, Booking.com manages over 1,000 simultaneous experiments across its product suite, with hundreds active on mobile. Every minor adjustment undergoes A/B testing via our proprietary experimentation library before reaching the user. A unified design system ensures product consistency and makes design goals transparent to all contributors, not just maintenance engineers. This article examines two specific engineering challenges solved using Kotlin Multiplatform (KMP) and Compose Multiplatform (CMP): Developing a shared experimentation library to ensure uniform experiment assignments across Android and iOS. Using Compose Multiplatform to host our Android design system in a web browser, bridging the gap between design concepts and implementation. While both cases use the same underlying technology, each provides unique insights into multiplatform development. Use case 1: shared experimentation library on Android and iOSThe problem with two implementations Historically, our internal experimentation library, responsible for managing experiment assignments, evaluations, and tracking on mobile, was maintained as two distinct codebases: a mix of Java and Kotlin for Android and Objective-C for iOS. While intended to be identical, managing two languages with fluctuating team resources inevitably led to logic drift. Discrepancies in event-tracking and experiment-fetching behaviours emerged, though they wer ## A Story of Delayed AWS Pipelines DevFeed: [A Story of Delayed AWS Pipelines]() Original publisher: [Read original article]() Author: Vladimir Romashov Published: 2026-05-08T14:23:22Z Content type: article Language: en Sources: [Booking.com Development - Medium]() Topics: [Amazon Web Services](), [Terraform](), [AWS Organizations](), [Infrastructure as code](), [CI/CD](), [Security]() Tags: [aws](), [aws-organizations](), [booking](), [ci-cd](), [ci-cd-pipeline](), [infrastructure-as-code](), [pii](), [terraform]() ### AI overview The article investigates delays in Terraform CI/CD pipelines caused by repeated use of the aws_organizations_organization data source and interactions with the AWS Organizations API. Testing found that roughly 1 in 10 Terraform pipelines were affected, with delays ranging from 1 to 15 minutes, while comparable CDK pipelines were not delayed. ### Source excerpt How a seemingly simple AWS API call can silently slow down your CI/CD pipelines Review/co-researcher: Gonzalo Ulla The Mystery It started with a line in one of our team's CI/CD logs that nobody expected: module.project.module.user_buckets.module.s3_bucket.data.aws_organizations_organization.current: Still reading... [15m10s elapsed] 15 minutes and 10 seconds -- just to read organization data. A value that should return in milliseconds was holding up entire pipelines. After digging deeper, we discovered this wasn't a one-off issue. During testing, roughly 1 in 10 pipelines containing Terraform were affected, with delays ranging from 1 to 15 minutes each. At Booking.com, we deploy and manage our AWS infrastructure using two primary Infrastructure as Code (IaC) technologies: Terraform and AWS Cloud Development Kit (CDK). To standardize and enforce our compliance and security controls, we maintain a set of internal Terraform and CDK modules to provision resources that handle personally identifiable information (PII). Interestingly, only Terraform pipelines were affected by this issue -- CDK ones running in the same accounts and against the same AWS Organization were completed without any delays. [spoiler alert/] CDK uses CloudFormation under the hood, which doesn't make additional Organizations API calls directly. [/spoiler alert]. This ruled out a general AWS-side outage or account-level throttling and pointed us toward something specific to how Terraform interacts with the Organizations API. This is the story of how we tracked down the root cause -- and why the fix isn't as simple as you'd think. What is aws_organizations_organization? Terraform's aws_organizations_organization data source retrieves information about, guess what, your AWS Organization. On the surface, it maps to the AWS DescribeOrganization API call -- a flat request. No iteration. No pagination. Simple... Or so we thought. The First Clue: Reproducing the Issue The references to the Organizations API mostly c ## Breaking the Loop: How we migrated our backup catalog for 250+ MySQL clusters to AWS DevFeed: [Breaking the Loop: How we migrated our backup catalog for 250+ MySQL clusters to AWS]() Original publisher: [Read original article]() Author: Ioannis Androulidakis Published: 2026-02-19T14:19:52Z Content type: article Language: en Sources: [Booking.com Development - Medium]() Topics: [migration](), [Amazon RDS](), [MySQL](), [Amazon Web Services](), [backups](), [Cloud](), [on-prem]() Tags: [amazon-rds](), [aws](), [backup](), [cloud](), [cloud-migration](), [data-backup](), [database](), [databases](), [migration](), [mysql](), [on-prem](), [relational-databases](), [reliability-engineering]() ### AI overview Booking.com's Database Engineering team describes migrating the backup catalog orchestrator's backend for more than 250 production MySQL clusters from a self-managed on-premises MySQL database to managed Amazon RDS for MySQL in AWS. The article discusses the migration's challenges, implemented solutions, and lessons learned. ### Source excerpt This post was originally published internally on May 9, 2025 and has been reworked for a public audience. Authors: Ioannis Androulidakis, Mohammed Gaafar Intro The Database Engineering team at Booking.com is constantly looking for ways to improve database reliability and support scaling our business. In 2025 we completed a major milestone in our effort to modernize our infrastructure: we seamlessly migrated the backend of the orchestrator that schedules and manages the daily backups of 250+ production MySQL clusters. More specifically, we moved from a self-managed MySQL database running on premises to a managed Amazon RDS MySQL database running in the cloud. This blog post delves into the challenges we faced, the solutions we implemented, and some key lessons we learned along the way. We are moving to the cloud (gradually) Cloud adoption is a journey, not a switch. Over the past few years the adoption of AWS solutions at Booking.com has been growing rapidly across different business units, allowing teams to be more autonomous, run their databases in the cloud and solve known issues with their old on-premise setup. Like customer teams, we are running our own databases to power the core services that we offer and manage databases efficiently at scale. To name a few: automatic failover of writable primaries, auto-scaling of read-only replicas, service discovery, capacity planning, online schema changes, user access management, volume backups, etc. Traditionally, the Database Engineering team has been running databases on-premises. In the emerging era of cloud databases, we wanted to compare our in-house offerings with existing cloud databases and bridge the gap between the two. Knowing that we lacked deep, hands-on experience with the operational realities of running critical infrastructure on AWS, we saw this as a unique opportunity to learn more about cloud databases while also improving the reliability of our systems. Long story short, we decided to prioritize the m ## How Booking.com Uses Backstage to Support Distributed Ownership in Its Engineering Portal DevFeed: [How Booking.com Uses Backstage to Support Distributed Ownership in Its Engineering Portal]() Original publisher: [Read original article]() Author: Matthew Pennell Published: 2026-02-02T16:26:13Z Content type: opinion Language: en Sources: [Booking.com Development - Medium]() Topics: [Backstage](), [developer-productivity](), [Tooling](), [ui]() Tags: [backstage](), [company](), [developer-productivity](), [platform](), [software-development](), [tooling](), [user-interface](), [ux-design]() ### AI overview Booking.com describes adopting Backstage for its internal Engineering Portal, where autonomous teams own different features and tooling. The article explains that Backstage's plugin-based architecture provided the flexibility needed to support the company's complex engineering environment while addressing interface inconsistency and developer friction. ### Source excerpt The necessity of imperfection: Designing for distributed ownership in Backstage Imagine an internal engineering platform -- tooling that is accessed by thousands of developers every day -- where every new feature, every piece of critical functionality, is designed, built and maintained by a different, autonomous team. For years, that was the reality of our internal tooling at Booking.com; a productive, necessary chaos. Engineers had the freedom to build and deploy exactly what they needed, but the cumulative effect was a user interface that was about as far from being a unified ecosystem as it was possible to get. The resulting friction, cognitive load, and sheer inconsistency was a silent, daily tax on developer productivity. Booking.com, like any established tech company, has a sprawling collection of internal tools. Some are commonplace across the industry, such as Google Drive, Jira, Workday, Zoom, Figma and Miro. Others are so specific to the way that we work that building them ourselves has always been the most practical option. And somewhere in the middle are systems we could build, but that would be better served by a framework which handles the fundamentals and lets us focus on the details unique to our environment. Our Engineering Portal is one of those systems: essential for governance, ownership, productivity and visibility, yet also something that thousands of engineers should be able to use easily without having to think too hard about it. There are plenty of off-the-shelf developer portals available. Port, Cycloid, Configure8, Rely and OpsLevel among others all offer their own take on managing engineering ecosystems and come with slick interfaces, integrations and (of course, nowadays) various forms of AI assistance. However, in such a mature and complex environment as Booking (approaching 30 years in business at the time of writing), the deciding factor wasn't the surface polish -- it was flexibility. After all that time layering, modernising and occasi ## Tactical Coding Assistants DevFeed: [Tactical Coding Assistants]() Original publisher: [Read original article]() Author: Pieter Tolsma Published: 2025-07-03T08:53:09Z Content type: opinion Language: en Sources: [Booking.com Development - Medium]() Topics: [Large Language Model](), [Development](), [Software Engineering](), [Architecture & Design](), [Refactoring](), [Claude](), [Artificial Intelligence]() Tags: [ai](), [claude](), [coding](), [coding-assistant](), [complexity](), [design](), [development](), [genai](), [llm](), [refactor](), [review](), [software-design]() ### AI overview The article compares tactical and strategic programming and applies that distinction to coding assistants. Drawing on the author's experience, it argues that assistants such as Gemini 2.5 Pro and Claude 3.7 can implement clearly specified tasks effectively, but may produce excessive complexity, duplicated behavior, and difficult-to-maintain code when used without architectural review. ### Source excerpt Over the past 15 months I have been actively working with LLM's in my job as a software engineer. I have had many moments where I thought singularity was here, but then almost immediately after I would see the agent fall flat on its face. I have become interested in figuring out when and why these new tools fail, in the hope that it can help me use these tools to their maximum potential while still keeping control over the quality of what I commit. In this short article, I want to expand on a recent observation. Generated using Gemini Imagen 4 In the book 'A Philosophy of Software Design' by John K. Ousterhout, a great analogy is made between two different modes of development: tactical and strategic programming. Tactical programming: this is a shortsighted approach focused on completing the immediate task as quickly as possible. Here, the primary goal is to make a feature or bug fix work in the most direct way. You can imagine what will happen if you have a team of engineers that only works like this: technical debt will pile up fast. Generated using Gemini Imagen 4 On the other side there is strategic programming: this involves a higher level of thinking. A strategic programmer is not finished when the feature is implemented. They take a step back and review the architecture, to see if any abstractions can be made. Does the current approach overcomplicate things? Can we refactor things? The focus here is on design, where the engineers main goal is to keep complexity at bay. These two analogies hooked onto what I thought about the current state of coding assistants. In my experience, some of the current (mid-2025) state of the art coding assistants (Gemini 2.5 pro, Claude 3.7) are extremely adept tactical programmers. Assuming you give them a clear description of what you need implemented, they will go ahead and do it for you (with quite a high success rate in my experience). We humans are limited by many things, such as the speed at which we can physically press k ## Unlocking the Power of Customization: How Our Enrichment System Transforms Recommendation Data... DevFeed: [Unlocking the Power of Customization: How Our Enrichment System Transforms Recommendation Data...]() Original publisher: [Read original article]() Author: Juan Pablo Lorenzo Published: 2025-06-18T08:02:41Z Content type: article Language: en Sources: [Booking.com Development - Medium]() Topics: [recommendation systems](), [AI, ML & Data Engineering](), [implementation]() Tags: [ai](), [architecture](), [article](), [data](), [java](), [machine-learning](), [recommendation-system](), [recommendations](), [software-development]() ### AI overview This Booking.com engineering article describes an Enrichment System for its Recommendation Platform. The system is intended to provide reusable contextual data about recommendations, while addressing the complexity and tight coupling of the previous enrichment process. ### Source excerpt Unlocking the Power of Customization: How Our Enrichment System Transforms Recommendation Data Enrichments How are accurate property prices on Booking.com connected to machine learning that recommends appealing property photos? What about the number of users who have wishlisted a property? And how can developers assess if their recommendation models effectively boost traveler clicks? None of these pieces of information are recommendations on their own, but they're crucial when providing our travelers good recommendations. For years, our Recommendation Platform has handled this process, but we needed a better way. Recommendation Platform is a service created to empower teams with adaptive, scalable, and personalized recommendations. These recommendations are integrated into every step of the customer journey, covering everything from attractions and flights to travel destinations and accommodation. We allow teams to use machine learning models combining multiple providers to achieve traveler recommendations. The platform is developed to be self-served and new use cases could be implemented by those teams. Check out our Self-Serve Platform for Scalable ML Recommendations article for a deeper look into how the platform works. Recommendations are valuable by themselves, but in most cases, information about the specific recommendation is just as important. Previously, adding such information was complex, lacked isolation, and had limited reusability. The new Enrichment System aims to overcome these challenges. The Enrichment System is a unified, extensible and scalable approach to support enrichments in the Recommendation Platform. When using data to develop new capabilities, being fast and efficient is key. But our previous enrichment process often stood as a barrier rather than a facilitator. Here's why: Complexity of implementation: imagine a developer eager to enhance a recommendation with new data insights. Under the old system, implementing a new enrichment require ## Anomaly Detection in Time Series Using Statistical Analysis DevFeed: [Anomaly Detection in Time Series Using Statistical Analysis]() Original publisher: [Read original article]() Author: Ivan Shubin Published: 2025-04-15T18:45:36Z Content type: tutorial Language: en Sources: [Booking.com Development - Medium]() Topics: [Time Series](), [Statistics](), [Monitoring](), [data](), [Website]() Tags: [analysis](), [anomaly-detection](), [article](), [behavior](), [data](), [grafana](), [metrics](), [monitoring](), [outlier-detection](), [sre](), [statistics](), [time-series](), [web]() ### AI overview This article explains how to build a statistical anomaly detection system for time series data. It describes why static thresholds and comparisons with the same point one week earlier can miss recurring or gradual problems, and introduces standard deviation as a foundational statistical measure. ### Source excerpt Setting up alerts for metrics isn't always straightforward. In some cases, a simple threshold works just fine -- for example, monitoring disk space on a device. You can just set an alert at 10% remaining, and you're covered. The same goes for tracking available memory on a server. But what if we need to monitor something like user behavior on a website? Imagine running a web store where you sell products. One approach might be to set a minimum threshold for daily sales and check it once a day. But what if something goes wrong, and you need to catch the issue much sooner -- within hours or even minutes? In that case, a static threshold won't cut it because user activity fluctuates throughout the day. This is where anomaly detection comes in. What exactly is anomaly detection? Instead of relying on simple rules, it involves analyzing historical data to spot unusual patterns. There are various ways to implement anomaly detection, including machine learning and statistical analysis. In this article, we'll focus on the statistical approach and walk through how we built our own anomaly detection system for time series data from scratch at Booking. The Naïve Approach One common mistake I've seen across different companies and teams is trying to detect anomalies by simply comparing a business metric to its value exactly one week ago. This week vs previous week At first glance, this approach isn't entirely useless -- you can catch some anomalies, as shown in the image above. But is it a reliable long-term solution? Not really. The big flaw is that today's anomaly becomes next week's baseline. That means if the same issue occurs again at the same time next week, it may go completely unnoticed because we're now comparing against a flawed reference point. Outage in previous week That doesn't look right, our simplistic approach doesn't know that last week's data was compromised. Another limitation of this method is that it only considers a single week at a time. But what if perform ## Fitting Scrum for Software Development -- Part II DevFeed: [Fitting Scrum for Software Development -- Part II]() Original publisher: [Read original article]() Author: Egor Savochkin Published: 2025-02-27T14:06:58Z Content type: tutorial Language: en Sources: [Booking.com Development - Medium]() Topics: [Agile](), [Development](), [Software Engineering](), [software-development]() Tags: [agile](), [development](), [engineering](), [programming](), [scrum](), [software-development](), [technology]() ### AI overview This article argues that Scrum teams developing software should adapt Scrum while retaining its core principles and integrating strong engineering practices. It focuses on breaking product backlog items into small, value-driven tickets based on acceptance criteria rather than implementation activities, while considering dependencies and clear ticket naming. ### Source excerpt Scrum, AgileFitting Scrum for Software Development -- Part IIBreak down stories like a boss and a few more trickssource Many software teams use Scrum, but it comes with challenges. While it originated in software development, its creators made it broad enough to work across industries. The idea? Teams should adapt and improve it while sticking to core principles. But in reality, that rarely happens. Instead, teams get stuck in rigid processes, perfecting rituals instead of shaping them to fit their needs. Another big consequence is that Scrum emphasises management but overlooks engineering practices. But without strong engineering foundations, it barely works for software development [Fowler09]. In this series, we adjust Scrum to better fit software development, integrating engineering practices where needed. In the first article, we explored how to make daily stand-ups more efficient -- focusing on blockers and tracking only the tickets that matter. We also advised against breaking backlog items into generic tasks like development, testing, or support. We recommended considering a ticket done only after shipping it to production. That likely raised even more questions. How should we break them down instead? With many small, value-driven tickets, how do we ship them despite dependencies? And how can we name tickets in a way that is clear, avoids confusion, and conveys maximum information? Let's tackle those questions. Break down by acceptance criteria. Earlier we talked about tracking value instead of activities. Sounds great in theory, but in practice? Not so simple. Scrum teams work in time-boxed iterations, usually two weeks long. To fit within a sprint, the team needs to break down PBIs (product backlog items) into smaller pieces. And this is where teams often struggle. The easiest -- and most tempting -- way to split work is by implementation activity. This allows for endless breakdowns, right down to a single line of code. But this approach comes with several prob