How Airbnb scaled its backend

Airbnb's original monolith, and still a significant part of its backend today, is built on Ruby on Rails - chosen in the company's early days for how quickly it let a small team ship a working product.

As Airbnb split its monolith into services, it adopted Thrift to define and call APIs between those services - a way for one internal service to call another with a strongly typed contract instead of loosely-defined HTTP calls.

A tool Airbnb built internally to schedule and monitor complex data pipelines - many small jobs with dependencies between them - and later open-sourced; it's since become one of the most widely used workflow schedulers in the industry.

Used for dashboards and analytics that need to query very large volumes of event data with low latency, where a traditional data warehouse would be too slow to query interactively.

Airbnb migrated its service infrastructure onto Kubernetes, moving away from earlier in-house deployment tooling, to get a more standard, community-supported way of scheduling and scaling its large number of services.

Airbnb's core transactional data - listings, bookings, users - has long lived in MySQL, sharded and scaled as the company grew rather than replaced outright.

Used for a number of newer backend services built after the move away from a single Rails codebase, particularly infrastructure-facing services where the JVM's performance and tooling ecosystem were a better fit than Ruby.

Moves event data - bookings, search activity, pricing changes - between services and into the data pipelines that feed tools like Airflow and Druid, without every producer and consumer needing to be directly connected.