How Skyscanner Migrated 300 Microservices to Event-Driven Architecture

Lucas: If you're running an engineering org and someone tells you they want to move three hundred microservices from synchronous REST calls to an event-driven architecture, your first reaction might be to ask if they've lost their mind. Luna: Yeah, that's not a trivial lift. But Skyscanner actually did it over about two years, and the results are pretty telling. Lucas: Exactly.

Skyscanner - the travel meta-search platform, hundreds of millions of queries per day - they started this migration in 2023 after a particularly nasty outage. A single service failure cascaded through synchronous HTTP calls and took down the entire price search pipeline for nearly an hour. Luna: I remember that. During peak booking season, too.

So that was the trigger? Lucas: That was the trigger. They'd been running a fairly standard microservices setup for years - each service owned its own data, communicated via REST, some gRPC. But as the number of services grew, the dependency graph got more tangled.

A failure in one place could ripple through five or six services before anyone could stop it. Luna: And the travel domain is particularly nasty because every query touches multiple services - flights, hotels, car rentals, pricing, availability, user preferences. It's a fan-out scenario. Lucas: Right.

So their CTO at the time, Tom Hinton, made the call: they would move to an event-driven architecture with Apache Kafka as the backbone. The idea was to decouple services so that if one goes down, the others can still process messages from the queue and catch up later. Luna: But a full rewrite of three hundred services is insane. They must have done this incrementally.

Lucas: They used a strangler fig pattern - exactly. They didn't rewrite anything from scratch. Instead, they identified the most critical data flows: price search, booking, availability. For each flow, they introduced a new event stream alongside the existing synchronous path.

Over time, new consumers subscribed to the event stream, old consumers were migrated, and eventually the synchronous path was cut. Luna: So they ran both systems in parallel for a while. That's a lot of operational overhead. Lucas: Huge overhead.

But it meant they could roll back quickly if something broke. The key insight was that they didn't try to migrate all services at once - they migrated data flows. A 'data flow' is a set of services that participate in a specific user-facing feature, like 'get flight prices'. They reorganized their engineering teams around those flows, not around their old service boundaries.

Luna: That's actually a really interesting organizational change. You're basically aligning the team structure to the new architecture before the architecture is fully built. Lucas: Exactly. They called them 'value streams'.

Each value stream had end to end ownership of a business event - like 'PriceUpdated' or 'BookingConfirmed'. The teams were responsible for producing and consuming events for their domain. That forced them to think in terms of contracts, not just APIs. Luna: And contracts are where things get messy.

What format did they use? Avro? Protobuf? Lucas: They went with Avro, with a schema registry on top of Kafka.

Every event had a schema, and the schema was versioned. Breaking changes required a new major version, and consumers had to explicitly opt in. That gave them confidence to evolve schemas without breaking downstream services. Luna: So the hard part wasn't the Kafka infrastructure - it was getting teams to agree on schemas and handle versioning properly.

Lucas: That's exactly what they said in their post-mortem. The technology was the easy part. Kafka is well understood. The hard part was the data contracts - getting every team to think about what events they produce, what guarantees they offer, and how to handle backward compatibility.

They had to create an entirely new internal documentation standard for event schemas. Luna: I've heard similar stories from other companies. The social challenge often outweighs the technical one. Lucas: And if you're finding these kinds of deep-dive conversations valuable for what you're building or running, it's worth knowing that there's a simple way to support the show.

A couple of dollars a month is genuinely what keeps these going - buy me a coffee dot com slash fexingo, if you've gotten something out of them. Luna: Yeah, it really does make a difference. Keeps us ad-free and focused on the stories that matter. Lucas: So back to Skyscanner.

One of the more surprising metrics they shared after the migration was a sixty percent reduction in p99 latency for price searches. Luna: That's huge. Where did the latency savings come from? I'd expect event-driven systems to be more resilient, but not necessarily faster.

Lucas: Right, that's a great question. The savings came from eliminating synchronous fan-out. In the old system, when a user searched for flights, the search service would make HTTP calls to five or six downstream services in sequence or parallel - pricing, availability, airline data, etc. Each call added network latency, queueing delay, and potential retry overhead.

In the new system, the search service publishes a 'SearchRequested' event, and all the downstream services consume that event asynchronously, process it, and publish their own events back. The search service aggregates the results from the event stream. The key is that the downstream services can precompute some data and cache it, so when the event comes in, they respond faster. Luna: So it's not just about moving from synchronous to asynchronous - it's about enabling new patterns like event sourcing and CQRS that weren't feasible before.

Lucas: Exactly. They also adopted a pattern where some services maintain local caches that are updated via events. That means the service can respond to queries without making any network calls at all - just read from its own cache. That's where the big latency wins came from.

Luna: What about consistency? If you're caching data updated asynchronously, you're accepting some degree of staleness. Lucas: They accepted eventual consistency for most data. For price searches, a few seconds of staleness is acceptable - users often refresh anyway.

For bookings, they kept synchronous checks. The system wasn't purely event-driven for all operations; it was a hybrid. They called it 'event-aligned' rather than event-sourced. Luna: That's a pragmatic approach.

Not every operation needs to be asynchronous. So what was the migration timeline like? Lucas: They started in early 2023 with the price search flow - it was the highest traffic and most painful when it failed. That took about six months to fully migrate.

Then they moved to availability, then booking, then ancillary services like recommendations and user profiles. By mid-2025, about two hundred of the three hundred services were fully event-driven. The remaining hundred are on a slower track because they're lower traffic or have legacy dependencies. Luna: So they're not forcing a full migration.

They're letting teams move at their own pace as long as they adopt the new patterns for new features. Lucas: That's the strategy. And it's working. They've had zero cascading failures since the migration.

The system degrades gracefully - if a downstream service goes down, the events queue up and get processed when it comes back. Users might see slightly stale data, but they don't see errors. Luna: One thing I find interesting is that they chose Kafka over something like Pulsar or RabbitMQ. Any idea why?

Lucas: They evaluated a few options. Kafka won because of its mature ecosystem, strong durability guarantees, and the fact that they already had some Kafka experience from their data pipeline team. The operational complexity of Kafka was a concern, but they figured they could manage it with their existing infrastructure team. And they use Kafka's log compaction feature heavily for state restoration.

Luna: Log compaction is really useful for event sourcing - it lets you replay events to rebuild state without keeping every single event forever. Lucas: Exactly. They use compacted topics for things like 'FlightScheduleChanged', where they only need the latest state per flight. That keeps their storage manageable.

Luna: So what's the one lesson you'd take away from Skyscanner's migration for a CTO considering a similar move? Lucas: I'd say: don't start with technology. Start with data contracts. Get your teams to agree on what events exist, what they mean, and who owns them.

If you can't get that right, the Kafka cluster won't save you. Skyscanner spent the first three months just defining event schemas and governance before writing a single line of streaming code. Luna: That's a good lesson. And it's easy to overlook when you're excited about the infrastructure.

Lucas: Yeah. The infrastructure is the fun part. The contracts are the hard work. But if you do the hard work first, the migration becomes almost mechanical.