Airbnb

11 posts

medium.com/airbnb-engineering

Filter by tag

airbnb

Academic Publications & Airbnb Tech: 2025 Year in Review (opens in new tab)

Airbnb’s 2025 research program expanded across major academic venues, with a focus on applying AI, machine learning, and data science to search, ranking, personalization, and marketplace optimization. The company strengthened its presence at KDD and CIKM while broadening into NLP, optimization, and measurement science. Its research emphasized practical systems that improve experimentation, retrieval, recommendations, ranking quality, and booking conversion. ## Research Expansion in 2025 - Airbnb presented research at established conferences including KDD and CIKM, while expanding into venues such as COLING, LION, and VLDB. - Researchers used these conferences to: - Share production-scale findings with academic and industry peers. - Develop new collaborations. - Learn about emerging methods. - Mentor early-career researchers. - The work was organized around themes including applied machine learning for search and personalization, and NLP and LLM systems in production. ## Search Ranking and Marketplace Retrieval at KDD KDD is a leading conference for data mining, knowledge discovery, and large-scale analytics. Airbnb has presented there since 2018, and its 2025 contributions focused on improving search experimentation and location retrieval. - **Interleaving and counterfactual evaluation** - Airbnb introduced techniques for evaluating search-ranking ideas before launching full A/B tests. - These methods help teams identify promising experiments more quickly. - They are especially useful for accommodation booking, where long conversion cycles can make statistical significance slow to achieve. - The goal is to accelerate experimentation without compromising evaluation accuracy. - **Extreme classification for audience expansion** - Airbnb presented a high-precision approach to retrieving relevant geographic areas in its two-sided marketplace. - The system uses categorical location cells to identify areas containing listings a guest might realistically book. - This helps balance Airbnb’s diverse global inventory with users’ preferences for location, amenities, style, and price. - Airbnb also presented work on **TSMO**, or Two-sided Marketplace Optimization, and indicated that some technologies might eventually be open-sourced. ## Search and Recommendation Advances at CIKM At CIKM 2025, Airbnb’s Relevance and Personalization team had five peer-reviewed papers accepted. The work addressed search, recommendations, ranking metrics, multimodal representations, and user comparison behavior. - **Recommendations for overly narrow searches** - Airbnb developed a system that suggests alternatives when a guest’s search returns too few accommodations. - Suggestions may include different dates, broader amenity requirements, or adjusted price ranges. - The system aims to reduce search frustration and increase booking rates. - **Map-specific ranking optimization** - Maps account for approximately 80% of Airbnb search interactions. - Traditional feed-ranking assumptions do not accurately represent how users view and interact with map results. - Airbnb introduced a map-specific version of NDCG, a ranking-quality metric. - Experiments showed that optimizing for this metric improved bookings. - **BiListing multimodal embeddings** - BiListing combines listing text and photos into unified embedding representations. - It uses large language models and pretrained language-image models as ranking signals. - The approach produced a reported 0.425% improvement in normalized discounted booking gain and generated tens of millions of dollars in incremental revenue. - **Beyond pairwise learning-to-rank** - Airbnb proposed a learning-to-rank method that models interactions between items during pairwise comparisons. - This provides a more realistic view of what users prefer when evaluating search results. - The paper also describes efficient implementation techniques and online and offline evaluation results. - **Learning to Comparison-Shop** - The LTCS system models how users compare multiple listings rather than evaluating each listing independently. - It produced statistically significant improvements of 1.7% in NDCG and 0.6% in booking conversion rate. - The work reflects Airbnb’s broader effort to make ranking models sensitive to the context of an entire results page. ## NLP and Production LLM Systems - Airbnb also highlighted NLP and production LLM research, including participation in EMNLP. - Relevant application areas include: - Customer support. - Search and discovery. - Trust and safety. - EMNLP covers language-model architectures, training strategies, safety, evaluation, datasets, and open-source tooling. Airbnb’s 2025 publications show a strong emphasis on research that translates directly into marketplace performance. The most practical opportunities involve faster experimentation, context-aware ranking, multimodal listing understanding, and recommendation systems that help guests recover from overly restrictive searches.

airbnb

Safeguarding Dynamic Configuration Changes at Scale (opens in new tab)

Airbnb’s Sitar platform is designed to make runtime configuration changes as safe and reliable as code deployments. It combines Git-based reviews, automated validation, staged rollouts, observability, and fast rollback with a highly available distribution system. Separating decision-making from config delivery, while using local caches, lets teams change behavior quickly without unnecessarily increasing outage risk. ## Requirements for a Modern Configuration Platform - Provides an end-to-end workflow for defining, reviewing, testing, and deploying configuration. - Treats configuration like code: - Versioned and reviewable - Auditable - Governed by ownership and access controls - Supports isolated local and canary testing before production rollout. - Accommodates multiple tenants with different: - Deployment triggers - Guardrails - Rollout strategies - Enables incident responders to make emergency changes while preserving auditability and visibility into who changed what, when, and which users or services were affected. ## Sitar’s Architecture Sitar consists of four major layers: - **Developer-facing layer:** Configs are usually managed through GitHub pull requests. The Sitar portal supports exceptions and administrative operations, including emergency deployments. - **Control plane:** Validates schemas, enforces ownership and authorization, selects rollout targets, manages progressive deployment, and supports rollback and targeted testing. - **Data plane:** Stores config values and versions as the source of truth, then distributes updates reliably and efficiently. - **Agents and client libraries:** An agent sidecar fetches subscribed configs and maintains a local cache. In-process client libraries read from that cache and expose values to application code, with optional fallbacks. A typical change moves from a Git workflow through validation and rollout decisions, into the data plane, and finally to sidecars and application clients. ## Git-Based Configuration Management - GitHub is the default interface because it integrates with Airbnb’s existing CI/CD systems and review practices. - Teams can use pull requests, mandatory reviewers, approval flows, and complete change history. - Related configs are grouped into tenants with defined owners, custom tests, and dedicated continuous-delivery pipelines. - The Sitar portal remains available for teams that need a UI or for urgent changes that must bypass the standard CI/CD process. ## Progressive Rollouts and Rollbacks - CI first checks schema correctness, expected structure, types, and other automated requirements. - Config changes require review and approval before deployment. - After merging, changes roll out gradually: - Start with a limited environment, AWS zone, or percentage of Kubernetes pods. - Evaluate the change at each stage. - Expand only when results are healthy. - Authors and stakeholders are notified when regressions are detected, and bad changes can be rolled back quickly. - Limiting the initial scope reduces the blast radius of configuration errors. ## Separating Control and Data Planes - The control plane decides whether and how a change should be deployed. - The data plane stores and distributes the resulting configuration. - This separation allows rollout policies and authorization logic to evolve independently from storage and delivery infrastructure. - Changes to one layer are less likely to disrupt the other. ## Local Caching and Resilient Clients - Each service runs an agent sidecar alongside its application container. - The sidecar periodically retrieves subscribed configs and persists them locally. - Client libraries read configuration from the local cache for fast, in-process access. - If the configuration backend becomes unavailable or degraded, services can continue using the last known good values. ## Practical Takeaway A reliable dynamic configuration system should combine code-like governance with runtime flexibility. Git reviews, validation, staged deployment, strong observability, plane separation, and local caching allow teams to respond quickly while keeping configuration failures contained and reversible.

airbnb

My Journey to Airbnb — Anna Sulkina (opens in new tab)

Anna Sulkina’s career journey moved from hardware diagnostics and frontend development into backend infrastructure and engineering leadership. Her experiences at Twitter taught her to design distributed systems for failure and to build consensus around transformative technologies like GraphQL. She joined Airbnb in 2022 because it aligned her passion for travel with an opportunity to strengthen developer infrastructure, organizational strategy, and engineering collaboration. ## Discovering Technology in Post-Soviet Ukraine - Sulkina grew up in Eastern Ukraine as the Soviet Union collapsed. - Her older brother introduced her to computers by bringing home hardware components and assembling a machine that loaded programs from a cassette player. - Seeing how individual components formed a working system inspired her to pursue technology. ## Learning English While Building Technical Skills - She studied programming at a Ukrainian university before immigrating to the United States. - Although she understood written English and knew how to program, communicating in English was initially more difficult than learning programming languages. - She took ESL classes while studying C++ and Java through Berkeley Extension. - Her first job was in hardware diagnostics at a five-person company. - A language barrier caused her to run out of time on a technical interview, but an interviewer familiar with her Berkeley class gave her another opportunity. - She eventually transitioned from C++ to Java, which became her primary language for many years. ## Moving Down the Stack and Into Leadership - Sulkina’s career progressed from hardware diagnostics to frontend, backend, and infrastructure engineering. - At the same time, she increasingly took on leadership responsibilities. - At Caymas Systems, her manager recognized her leadership potential and showed her the difference effective leadership makes. - At Comcast, she moved from individual contributor to engineering manager. - Coaching engineers, building software collaboratively, and developing high-performing teams convinced her that leadership was the right path. ## Lessons from Twitter’s Distributed Systems - During nearly nine years at Twitter, Sulkina advanced from first-line manager to director. - She worked through major operational events, including the “fail whale” period and the tweetstorm surrounding Ellen DeGeneres’s viral selfie. - Twitter’s transition from a monolith to microservices taught her that failure is inevitable in complex systems. - Resilient distributed systems must be designed to handle failures rather than assuming failures can be prevented. - Her cultural lesson involved turning promising ideas into adopted technologies. - She helped bootstrap Twitter’s GraphQL API, replacing legacy REST services. - The effort required leadership support, cross-team consensus, and stakeholder alignment, but ultimately improved product teams’ development velocity. ## Choosing Airbnb - Airbnb contacted Sulkina in 2022, when she felt ready to move beyond a well-established organization at Twitter. - The company appealed to her because it combined her professional interests with her personal passion for travel; she had been an Airbnb guest since 2013. - Airbnb’s Developer Platform organization had strong work happening in separate silos but needed clearer strategy, direction, and trust across engineering. - Sulkina began by clarifying the organization’s purpose and future direction. - Her early priorities included strengthening the organization, coaching leaders, and creating alignment within the team and with the teams it supported. - Over the following years, this work produced a high-performing organization with clearer strategy, stronger execution, and a focus on delivering business value. Sulkina’s story emphasizes that technical growth, organizational leadership, and personal motivation can reinforce one another. Her experience suggests that successful engineering leaders design for failure, invest in alignment, and use clear strategy to turn fragmented efforts into meaningful platform-wide impact.

airbnb

My Journey to Airbnb: Peter Coles (opens in new tab)

Peter Coles’s career connects mathematical training, academic economics, and practical data science. After studying game theory and market design, he moved from Harvard Business School to eBay and then Airbnb, where he could apply economic models to real-world marketplaces. At Airbnb, he helped build economics and data science teams, guide policy decisions, investigate pandemic-driven changes, and measure the company’s broader impact. ## From Mathematics to Economics - Coles grew up in Milwaukee and developed an early interest in marketplaces by trying to run a neighborhood rock stand. - He studied math at Princeton after briefly pursuing ancient history. - He earned a PhD in economics at Stanford, focusing on game theory—the study of strategic decision-making. - His mentor, Jon Levin, taught him to simplify complex research problems. - While studying in Germany, Coles traveled around Europe and stayed with strangers connected to classmates, unintentionally experimenting with a model similar to Airbnb. ## Studying Markets and Market Design - At Harvard Business School, Coles researched market design and taught with Al Roth, who later won the Nobel Prize in Economics. - His work focused on “matching,” or designing systems that pair participants from two groups when prices cannot directly balance supply and demand. - He studied participant strategy, signaling, and market mechanisms, including improvements to the market for PhD economists. - He also wrote business cases about companies such as Zillow, Microsoft, and Craigslist. - Although he valued academia, he found the long research and peer-review cycle was not a good long-term fit. ## Applying Economics at eBay - In 2013, Coles joined eBay as technology and the sharing economy were rapidly expanding. - He led an economics team created by Steve Tadelis and helped combine it with another group to form eBay’s Data Labs. - One notable project, “What’s It Worth,” developed a method for estimating the fair market value of items sold on eBay. - The work combined economic reasoning, practical marketplace knowledge, and statistical modeling. ## Building Airbnb’s Economics and Data Science Functions - In 2015, Coles joined Airbnb to help address the company’s growing regulatory challenges. - He built a global team of economists and data scientists to study short-term rentals and their relationship with cities. - The team used data to inform policy discussions and evaluate Airbnb’s effects on guests, hosts, and communities. - This role allowed Coles to connect economic theory with decisions affecting a rapidly expanding platform. ## Central Strategy & Insights - As Airbnb grew, executives needed analysis that crossed organizational boundaries. - Coles and Jackson Wang founded Central Strategy & Insights, known as CSI. - The team acted as “forensic investigators,” assembling evidence and narratives from company-wide data. - During the pandemic, CSI analyzed major changes in guest travel patterns and determined what kinds of supply Airbnb would need. - The team also led business reviews and prepared analyses for shareholders before Airbnb’s IPO. ## Measuring Airbnb’s Broader Impact - Coles later returned to policy-focused work with a larger economics organization. - The team developed models to guide Airbnb’s response to governments as travel recovered after the pandemic. - Economists and analysts evaluated Airbnb’s impact on hosts, guests, and society. - Their work included the US Economic Impact Report and expanded collaboration with academic researchers using Airbnb data. Coles’s experience suggests that marketplace companies benefit from combining rigorous economic research with hands-on data science. Moving between academia and industry enabled him to turn theories about market design into practical tools for product strategy, policy, and impact measurement.

airbnb

Pay As a Local (opens in new tab)

Airbnb launched more than 20 locally preferred payment methods across global markets in just over 14 months. The initiative aimed to improve checkout conversion, reach customers with limited access to cards, and provide familiar payment options. Airbnb achieved this by combining a replatformed, domain-oriented payments architecture with reusable PSP connectors and standardized payment-flow patterns. ## Why Local Payment Methods Matter - Local payment methods (LPMs) include: - Digital wallets such as M-Pesa and MTN MoMo - Online bank transfers - Real-time payment systems such as PIX and UPI - Regional payment schemes such as EFTPOS and Cartes Bancaires - They help Airbnb: - Increase conversion by offering trusted local options - Enter markets where card usage is limited - Serve customers without credit cards or traditional banking access - Airbnb identified more than 300 payment options worldwide. - For the initial rollout, it evaluated the top 75 travel markets and selected one or two methods per market, producing a shortlist of just over 20 integrations. ## Payments Platform Modernization - Airbnb separated payment capabilities from its core stays, experiences, and services businesses. - Its Payments LTA modernization replaced a monolith with domain-oriented services. - Core payment subdomains include: - Pay-in and payout - Transaction fulfillment and processing - Wallets and payment instruments - Ledger - Incentives and stored value - Issuing - Settlement and reconciliation - This structure improved reuse, extensibility, time to market, and team autonomy. ## Connector Architecture and Multi-Step Transactions - The processing domain uses connector and plugin-based integrations for payment service providers (PSPs). - Plugins support: - API- and file-based integrations - Payment routing and switching - Market-specific PSP behavior - Airbnb also introduced Multi-Step Transactions (MST), a PSP-agnostic framework for payments requiring multiple stages. - MST represents intermediate operations as Actions, including: - Redirects to external apps or websites - Strong customer authentication challenges - Payment-method-specific interactions - PSP plugins normalize these requirements into an `ActionPayload` and return an `ACTION_REQUIRED` transaction status. ## Three Standardized LPM Flow Types Airbnb analyzed its payment methods and grouped them into three reusable archetypes: - **Redirect flow:** The guest is sent to an external site or app, then returned to Airbnb. Examples include Naver Pay, GoPay, and FPX. - **Async flow:** The guest completes payment later through a QR code, push notification, or wallet app, while Airbnb receives confirmation through a webhook. Examples include Pix, MB Way, and Blik. - **Direct flow:** Payment credentials are entered within Airbnb and processed immediately, similar to card payments. Examples include Cartes Bancaires and Apple Pay. This classification reduced duplicate engineering work and made new integrations more predictable. ## Orchestrating External Payment Actions - For redirect payments: - Airbnb sends a charge request to the local vendor. - The vendor returns a `redirectUrl`. - The guest completes payment externally. - Airbnb receives a result token and uses it to confirm the transaction securely. - For asynchronous payments: - Airbnb sends a charge request and receives `qrCodeData`. - The checkout displays the QR code. - The guest pays in an external wallet. - The vendor sends a webhook, allowing Airbnb to mark the payment successful and confirm the order. - These flows required careful handling of app switching, session handoff, delayed confirmation, and synchronization between Airbnb and external providers. ## Outcome Airbnb’s rollout demonstrates that broad local-payment coverage depends less on building every integration independently and more on creating reusable abstractions. A modular payments platform, standardized flow archetypes, normalized PSP actions, and plugin-based connectors enabled the company to support diverse regional payment behaviors at global scale.

airbnb

GraphQL Data Mocking at Scale with LLMs and @generateMock (opens in new tab)

Airbnb’s `@generateMock` directive combines GraphQL schemas, product context, design references, and LLMs to generate realistic, type-safe mock data automatically. Integrated into the existing Niobe code-generation workflow, it reduces manual mock maintenance and helps client engineers prototype and test features before backend implementation is complete. ## Challenges with GraphQL Mocking - Manually creating large JSON responses or schema-generated objects is tedious and error-prone. - Client engineers often hardcode data or modify networking logic when the server is not yet ready, slowing frontend development. - Handwritten mocks drift out of sync as queries and schemas evolve. - Random generators and field-level resolvers lack the domain knowledge needed for convincing, meaningful data. ## Airbnb’s Goals - Eliminate hand-written mock data and ongoing maintenance. - Generate realistic data suitable for demos, snapshots, and tests. - Keep engineers in their normal local development workflow without requiring separate tools or repositories. ## The `@generateMock` Directive - Engineers can add `@generateMock` to GraphQL operations, fragments, or fields. - Optional arguments customize the generated data: - `id` identifies a mock and names generated helper functions. - `hints` provide instructions such as destinations, content, or desired density. - `designURL` links to a design mockup so generated names, addresses, and other values better match the intended UI. - The directive can be repeated with different arguments to create multiple mock variations. ## Integration with Niobe - After adding or changing `@generateMock` in a `.graphql` file, engineers run Niobe just as they would for ordinary GraphQL code generation. - Niobe generates: - JSON files containing the mock responses. - TypeScript, Kotlin, or Swift helpers for consuming the mocks. - Generated functions return instantiated, type-safe model objects for demo apps, snapshot tests, and unit tests. - Engineers can edit the generated JSON manually; Niobe preserves those changes during later generation runs. ## Context Used by the LLM Niobe supplies the LLM with information needed to create realistic results: - The mocked operations, fragments, fields, and their dependencies. - The relevant subset of the GraphQL schema and inline documentation. - Only schema types and fields needed to resolve the query, avoiding unnecessary context-window usage. - A snapshot image of the design referenced by `designURL`, generated through Airbnb’s internal design-document API.

airbnb

From Static Rate Limiting to Adaptive Traffic Management in Airbnb’s Key-Value Store (opens in new tab)

Airbnb evolved Mussel’s QoS system from static, per-client QPS limits into adaptive traffic management designed to maximize goodput. The newer approach accounts for the actual cost of requests, prioritizes critical workloads under stress, and detects hot keys or attack traffic before they overwhelm storage. Together, resource-aware quotas and real-time load shedding provide stronger protection against traffic spikes, uneven workloads, and DDoS-like bursts. ## Why Static QPS Limits Fell Short - Mussel is a multi-tenant key-value store serving millions of point and range reads across Airbnb. - Its original Redis-backed limiter assigned each client a fixed requests-per-second quota. - Requests exceeding the quota received HTTP 429 responses. - This model worked when backend effort roughly matched request count. - As usage grew, it could not account for: - The difference between a cheap one-row lookup and a 100,000-row scan. - Hot keys accessed by many clients simultaneously. - Localized storage-shard overload that affected unrelated traffic. - Sudden events such as bot floods, DDoS attacks, or large uploads. ## Resource-Aware Rate Control - Mussel replaced raw request counting with request units (RU), which represent estimated backend work. - RU calculations incorporate: - Fixed per-request overhead. - Rows and payload bytes processed. - Request latency, which distinguishes cached operations from disk-heavy ones. - The system uses calibrated linear formulas for reads and writes, with weights based on compute, network, and disk-I/O measurements. - Dispatchers debit a local token bucket according to each request’s RU cost rather than charging every request equally. - Periodic RU refills preserve simple, static quotas while making them more proportional to actual resource consumption. - Requests are rejected with HTTP 419 when the RU bucket is exhausted. - Load shedding remains separate, allowing latency-based protection to react dynamically without changing the underlying quota-refill mechanism. ## Load Shedding Under Sudden Stress - RU rate limiting smooths normal traffic but may react too slowly to rapidly changing workloads. - Mussel adds a load-shedding layer based on: - Traffic criticality. - A real-time latency ratio. - A CoDel-inspired queue-management policy. - Each dispatcher compares long-term p95 latency with short-term p95 latency. - A ratio near 1.0 indicates stable performance; a drop toward 0.3 signals rapidly increasing latency. - When stress crosses the threshold: - The system raises the effective RU cost for a designated lower-priority client class. - That class’s token bucket drains faster, causing its traffic to back off. - If conditions worsen, the penalty expands to additional classes. - Critical workloads, such as customer support and trust-and-safety traffic, can remain responsive while less important traffic is reduced. - The latency estimate uses the constant-memory P² algorithm, avoiding raw sample storage and cross-node coordination. ## Hot-Key Detection and DDoS Protection - Client-level quotas cannot prevent overload when many clients request the same popular key. - Mussel therefore detects skewed access patterns in real time. - When duplicate requests target a hot key, the system can protect storage by: - Serving responses from cache. - Coalescing identical requests before they reach the backend. - This approach protects the underlying shard whether the traffic comes from legitimate popularity, automation, or a DDoS burst. Mussel’s experience suggests that mature multi-tenant services should move beyond fixed QPS limits. Combining resource-based accounting, priority-aware load shedding, and hot-key mitigation provides a more effective way to preserve reliability while maximizing useful work during unpredictable traffic conditions.

airbnb

Building a Next-Generation Key-Value Store at Airbnb (opens in new tab)

Airbnb rebuilt Mussel, its key-value store for derived data, from a complex EC2-based system into a cloud-native NewSQL platform. Mussel v2 combines bulk ingestion, streaming writes, low-latency reads, flexible consistency, and automated operations while supporting more than 100 existing use cases. A gradual, reversible blue/green migration moved production workloads without data loss or customer-visible downtime. ## Why Airbnb Rebuilt Mussel - New use cases—including real-time fraud detection, personalization, and dynamic pricing—required both streaming updates and large-scale bulk ingestion. - Mussel v1 had become difficult to operate and scale: - Node changes required multi-step Chef scripts on EC2. - Static hash partitioning created hotspots and latency spikes. - Consistency options were limited. - Resource consumption and costs were difficult to track. - Mussel v2 provides Kubernetes-based automation, dynamic range sharding, configurable consistency, namespace tenancy, quotas, and usage dashboards. ## Mussel v2 Architecture ### Stateless Dispatcher - A horizontally scalable Kubernetes service translates client requests into backend queries and mutations. - It supports: - Dual writes and shadow reads during migration - Retries, rate limiting, and dynamic throttling - Service-mesh security and discovery - Point lookups, range queries, prefix queries, and low-latency stale reads - Each dataname maps to a logical table, simplifying access patterns. ### Kafka-Based Write Pipeline - Writes are first persisted to Kafka for durability. - The Replayer and Write Dispatcher apply them to the backend in order. - Kafka absorbs traffic bursts and supports consistency, migrations, bootstrapping, and upgrades. - Airbnb plans to eventually rely more directly on the distributed database for ingestion and replication to reduce latency and operational complexity. ### Bulk Loading - Mussel retains support for both: - **Merge** jobs, which add data to existing tables - **Replace** jobs, which swap in a new dataset - Existing Airflow onboarding workflows transform warehouse data into a standard format and upload it to S3. - A stateless controller coordinates ingestion, while Kubernetes StatefulSet workers load data in parallel. - Deduplication, delta merges, and insert-on-duplicate-key-ignore improve throughput and reduce unnecessary writes. ## Scalable Data Expiration - Mussel v1 depended on storage-engine compaction for TTL expiration, which became inefficient at scale. - V2 uses a topology-aware expiration service: - Namespaces are divided into range-based subtasks. - Multiple workers scan and delete expired records concurrently. - Scheduling limits interference with live queries. - Max-version enforcement and targeted deletes help manage write-heavy tables. - The result is faster, more visible, and more scalable retention management. ## Blue/Green Migration - The migration had to handle massive datasets, thousands of tables, and mission-critical traffic with zero data loss and no availability impact. - Because v1 lacked table-level snapshots and CDC, Airbnb built a custom migration pipeline. - Tables were selected and migrated individually according to usage and risk. ### Migration Stages - **Blue:** All production traffic continued serving from v1. - **Shadowing:** Bootstrapped v2 tables processed parallel reads and writes, but v1 still served responses. - **Reverse:** V2 served live traffic while v1 remained available as a fallback. - **Cutover:** After validation, traffic was permanently moved to v2 one dataname at a time. - Automatic circuit breakers and fallback logic enabled rapid rollback if v2 showed errors or replication lag. - Kafka’s replication stream maintained eventual consistency between the two systems throughout the transition. ## Practical Takeaway Mussel v2 demonstrates that large datastore rearchitectures can be made safe through incremental migration, durable event logs, shadow traffic, and reversible per-table cutovers. The key recommendation is to combine a more scalable backend with strong operational automation and migration tooling, rather than attempting a single disruptive replacement.

airbnb

Viaduct, Five Years On: Modernizing the Data-Oriented Service Mesh (opens in new tab)

Viaduct, Airbnb’s data-oriented service mesh, has evolved substantially over five years while retaining its core model: a central schema, hosted business logic, and re-entrant composition through GraphQL. Its usage has grown eightfold, supporting more than 130 teams and over 1.5 million lines of production code, without increasing operational overhead. Viaduct Modern now aims to simplify its developer API and establish stronger architectural boundaries, alongside the project’s release as open source. ## Adoption and Evolution - Viaduct traffic has increased by a factor of eight since 2020. - More than 130 teams now host code in Viaduct, supported by hundreds of weekly active developers. - The hosted codebase has grown to over 1.5 million lines, with roughly the same amount of test code. - Operational overhead has remained constant, incident-minutes have been cut in half, and costs have grown linearly with QPS. - Viaduct is now available as open-source software. ## Core Principles That Remain - **Central schema:** Viaduct provides one integrated schema connecting domains across Airbnb. - More than 75% of requests are internal. - The schema is developed by many teams but exposed as a connected graph. - **Hosted business logic:** Teams run business logic directly in Viaduct rather than maintaining separate microservices. - This reduces operational overhead and can allow standalone services to be retired. - Viaduct provides a serverless environment so developers can focus on application logic. - **Re-entrancy:** Hosted logic composes with other hosted logic through GraphQL fragments and queries. - This supports modularity. - It helps avoid the tightly coupled structure and maintenance problems associated with traditional monoliths. ## Problems with the Earlier Design - Viaduct’s APIs evolved reactively in response to individual use cases. - Multiple mechanisms emerged for accomplishing similar tasks, creating confusion for developers. - Some capabilities were well supported while others were not. - The framework’s layers had loose, inconsistent interfaces. - The boundary between Viaduct and hosted application code was weak. - These issues made framework improvements increasingly risky because changes could disrupt existing users. ## Simplifying the Tenant API - Viaduct Modern overhauls the developer-facing API and execution engine. - The new Tenant API reduces the implementation choices to two mechanisms: - **Node resolvers** - **Field resolvers** - The choice is determined by the schema rather than by ad hoc behavioral distinctions. - Resolver APIs have been unified wherever possible. - The goal is a smaller, more consistent surface that preserves successful ideas from the old API while removing unnecessary alternatives. ## Tenant Modules and Re-Entrant Composition - Viaduct uses modules and re-entrancy to provide boundaries similar to service definitions and RPC APIs in microservice architectures. - A tenant module combines: - Schema owned by a team - The code implementing that schema - Modules can create rich connections in the shared graph, but direct code dependencies between teams are discouraged. - Instead, teams declare their data requirements through GraphQL fragments and queries. ### Example: Extending the `User` Type - A Core User team owns the base `User` type and resolves fields such as `firstName` and `lastName`. - A Messaging team can extend `User` with a `displayName` field. - Its resolver declares that it needs `firstName` and `lastName`. - Messaging does not depend directly on Core User’s implementation or need to know where those fields originate. - This declarative model lets teams collaborate through the schema while preserving ownership and modularity. ## Framework Modularity - Viaduct Modern also restructures the framework itself. - The system consists of: - The GraphQL execution engine - The Tenant API - Hosted application code - Historically, the interfaces between these layers were weak, making performance and reliability improvements difficult to introduce safely. - The redesign focuses on stronger abstraction boundaries so the framework can evolve independently of application code. Viaduct’s modernization is intended to preserve its centralized, data-oriented model while making development simpler and framework evolution safer. The open-source release provides an opportunity for other organizations to evaluate or adopt this approach to schema-driven, modular service composition.

airbnb

Migrating Airbnb’s JVM Monorepo to Bazel (opens in new tab)

Airbnb migrated its tens-of-millions-of-lines JVM monorepo from Gradle to Bazel over 4.5 years, achieving faster builds, testing, IntelliJ syncs, and development deployments. The move was driven by Bazel’s scalable remote execution, hermetic builds, and ability to provide shared infrastructure across Airbnb’s language-specific repositories. A gradual rollout, extensive automation, and close collaboration with service teams were central to making the migration successful. ## Results of the Migration - Build CSAT increased from 38% to 68%. - Local build and test times became 3–5 times faster. - IntelliJ syncs became 2–3 times faster. - Development-environment deployments became 2–3 times faster. ## Why Airbnb Chose Bazel ### Faster Builds Through Remote Execution - Large Gradle builds frequently took more than 20 minutes locally, while pre-merge CI builds had a p90 of 35 minutes. - Gradle had already been optimized with powerful machines and build sharding, but sharding caused underutilization and duplicated shared work. - Bazel’s cacheable actions and remote build execution enabled thousands of actions to run in parallel on short-lived workers. - “Build without the Bytes” reduced the amount of build output developers needed to download. - Bazel analysis runs in parallel, unlike the often single-threaded configuration phase of large Gradle projects. - Remote execution also improved local build performance, not just CI performance. ### More Reliable and Reproducible Builds - Gradle tasks could access the entire filesystem, creating accidental dependencies and race conditions. - Bazel sandboxes expose only declared inputs to each action, preventing undeclared files from affecting builds. - Bazel’s remote execution runs actions in identical containers with strict resource limits. - Using remote execution for both local and CI builds reduced differences between developer and CI environments. ### A Shared Build Infrastructure Layer Because Airbnb’s web, iOS, Python, Go, and JVM repositories all use Bazel, the company could standardize infrastructure for: - Remote caching - Remote build execution - Affected-target calculation - Build Event Protocol instrumentation and logging ## Starting with a Proof of Concept - Airbnb first migrated Viaduct, a large GraphQL monolith platform. - Viaduct was selected because it was complex, had slow builds, affected roughly 300 product engineers monthly, and had an infrastructure team willing to collaborate. - Bazel and Gradle initially coexisted, allowing developers to choose either system. - The team ported Viaduct’s build logic and created an automated Bazel build-file generator because the Gradle dependency graph continued to change. - Although Bazel was initially 2–4 times faster locally, developers did not adopt it immediately. - The team spent several additional months fixing missing integrations and bugs before Viaduct engineers voluntarily switched. ## Scaling Across the JVM Monorepo - Airbnb expanded breadth-first, aiming to make the entire repository compile and test under Bazel. - Gradle and Bazel continued to coexist during the migration. - This allowed developers to use Bazel locally while deployments still relied on Gradle. - Gradle provided a fallback when Bazel infrastructure, such as remote caching or execution, experienced incidents. - Maintaining two build graphs was costly, so Airbnb invested heavily in automation rather than requiring developers to maintain Bazel files manually. ## Automated Build-File Generation - The generator was inspired by Gazelle but was built internally to meet stricter performance requirements and handle dependency cycles. - It parses Java, Kotlin, and Scala source files to identify packages, imports, and symbol declarations. - These relationships are used to construct a file-level dependency graph. - Since generation ran on every commit before merging, Airbnb added external caching to keep it fast. - CI publishes a cached repository index for each mainline commit, allowing the generator to rescan only directories changed since that commit. Airbnb’s experience suggests that a large build-system migration is most effective when introduced incrementally: prove the benefits on a representative service, automate maintenance, preserve a fallback during rollout, and address developer workflow issues before expanding across the organization.

airbnb

Taming Service-Oriented Architecture Using A Data-Oriented Service Mesh (opens in new tab)

Airbnb’s Viaduct rethinks the service mesh as a data-oriented layer rather than a network for routing procedural service calls. Built on GraphQL, it presents a unified data graph that hides microservice dependencies from consumers and improves modularity in large SOAs. The central schema can also coordinate service APIs, database models, and serverless data transformations, making system-wide changes more agile. ## The Problem with Large SOAs - Modern organizations may operate thousands of microservices connected through highly tangled dependency graphs. - These graphs resemble “spaghetti code” at the service level: - Changes become difficult to plan. - Teams must coordinate across many service boundaries. - Consumers often depend directly on multiple underlying services. - Airbnb argues that microservice architectures need stronger organizing principles and technical mechanisms for enforcing modularity. ## From Procedure-Oriented to Data-Oriented Design - Traditional procedural design groups procedures into modules with public APIs and hidden implementation details. - Data-oriented design instead organizes software around encapsulated data objects and the methods that operate on them. - Microservices have largely returned SOA to a procedural model: - Each service exposes collections of remote procedural endpoints. - Consumers must know which services provide the data they need. - Viaduct applies data-oriented principles to the service mesh itself. ## Viaduct’s GraphQL Data Mesh - Viaduct defines the mesh through a GraphQL schema containing: - Types and interfaces representing managed data. - Queries and subscriptions for reading data. - Mutations for updating data. - The schema forms a single graph spanning data owned by many microservices. - A consumer can navigate related data through one query, such as: - `productById { manufacturer }` - `productById { reviews }` - `productById { reviews { author } }` - Viaduct determines which services provide each requested field. - This hides service dependencies from consumers and prevents every client from building its own cross-service orchestration logic. ## The Central Schema - Unlike distributed GraphQL approaches that split schemas across modules or federated services, Viaduct treats the schema as one central artifact. - Airbnb uses schema-management primitives to let multiple teams collaborate while preserving a unified model. - Portions of the central schema can define individual microservice APIs. - Airbnb ultimately aims to use the same schema to define database structures. - This could improve “data agility”: - Database changes would no longer need manual translation through several API layers. - A single schema update could propagate changes from storage through services to clients. - Cross-team coordination and delivery times could be reduced. ## Serverless Derived Fields - Many SOAs contain stateless services that transform backend data for particular clients or presentation layers. - Viaduct supports derived fields computed by serverless cloud functions. - These functions operate on the graph without needing direct knowledge of the underlying microservices. - Moving transformation logic into stateless containers can: - Reduce the number of services. - Lower operational overhead. - Keep the core service graph simpler. ## Implementation and Operational Features - Viaduct is built on `graphql-java`. - It supports fine-grained field selection through GraphQL selection sets. - It uses data-loading techniques and an intra-request cache. - Reliability features include short-circuiting and soft dependencies. - Field-level observability shows which services consume particular data. - Its GraphQL interface enables use of established open-source tooling and interactive development tools. Viaduct’s practical recommendation is to place a unified data schema at the center of the architecture, allowing the mesh—not individual consumers—to manage service composition. This can make large SOAs more modular, easier to evolve, and better suited to serverless execution.