Airbnb Microservice Architecture
Jessica Tai, an engineering manager at Airbnb, recently talked at QCon about how Airbnb's architecture changed over the years and followed company development.
Also, we will talk about some common software architecture anti-patterns.
So, let's check the main phases and challenges at Airbnb.
Postman's VS Code Extension (Sponsored)
Postbot is now available across Postman with enhanced capabilities! The latest refresh of Postbot now offers a consistent, conversational interface available to you across your workspace. Learn how you can leverage Postbot throughout Postman to get contextual assistance.
Airbnb microservice architecture went through the following phases:
1. Monolith (2008 - 2017)
In the early years, from its inception in 2008 until around 2017, Airbnb operated on a monolithic architecture, primarily using a Ruby on Rails monolith. This setup initially served the company well, accommodating the full-stack engineers capable of handling end-to-end features within the single repository. However, as Airbnb experienced rapid growth and entered a hypergrowth phase, the monolith's limitations became increasingly evident. The application grew tightly coupled and complex, leading to significant scaling challenges (such as drawing team boundaries over the codebase). Also, one of the most critical issues was the slow deployments, which escalated from taking minutes to several hours or even a day, severely damaging developer productivity. All of this influenced Airbnb's decision to move to a Microservice architecture.
2. Microservices (2017 - 2020)
Categorizing services marked this shift into four distinct types:
Data fetching service for data read/write
Business logic service to combine data from multiple sources
Workflow for orchestration of various services
UI aggregation services to bring all of this to UI
A key strategy in this transition was the clear ownership of each service, with specific teams responsible for individual services. This restructuring led to a more specialized team setup, moving away from the full-stack approach to teams focused on the backend and specific data services. Despite the benefits of improved scalability and development speed, Airbnb faced new challenges in managing the complexity and dependencies of many services after a few years. The main issue was that to build an end-to-end feature, they needed to know different services, so multiple teams would need to be involved, and those teams needed to have the same priorities, which took time to manage.
Micro + Macroservices (2020 - Present)
In response to these emerging challenges, around 2020, Airbnb evolved its strategy to a hybrid model combining micro and macroservices. This approach centered on unifying APIs through a GraphQL interface, with a central data aggregator at its core (macroservice). The backend services were restructured to interact through this GraphQL interface, streamlining data flow and service interactions. This means that their backend services get data from the aggregator service (called service block), which then communicates with other microservices to gain data. Check the presentation in the comments.
Software Architecture Antipatterns
Architecture antipatterns focus on the system-level and enterprise-level organization of applications and components. The significance of architecture in software development has been repeatedly established by software research and experience despite the engineering discipline of software architecture being relatively young.
There are different types of software architecture antipatterns:
Autogenerated Stovepipe. This anti-pattern occurs when moving an established software system to a distributed architecture. An Autogenerated Stovepipe appears when transforming the current software interfaces to distributed interfaces. Numerous issues arise if the same idea is used in distributed computing.
Jumble. An unstable architecture is created when horizontal and vertical design components are blended. The resilience and reusability of the architecture and the system software components are constrained by the mixing of horizontal and vertical design elements.
Cover Your Asset. Because the writers avoid making crucial judgments, document-driven software processes frequently result in requirements and specifications that aren't very useful. The authors elaborate on options and take a safer approach to avoid making mistakes.
Vendor Lock-In. Systems that rely heavily on proprietary architectures experience vendor lock-in. Independence from vendor-specific solutions can be achieved through architectural isolation layers.
Design by Committee. It is a common antipattern used by standards organizations, resulting in too complex designs and lacking coherence. Poor meeting processes can be refactored into highly effective events by clarifying architectural roles and improving process facilitation.
Reinvent the Wheel. Between software projects, there is a persistent lack of technology transfer that causes significant innovation. Utilizing design knowledge buried in legacy assets can shorten time to market, lower costs, and lower risk.
Big Ball of Mud. It is a piece of software that has no discernible software architecture. While there may be many other causes for this, it frequently stems from the inexperience of the involved engineers.
If you want to learn more about Software Architecture Antipatterns, check here.
More ways I can help you
1:1 Coaching: Book a working session with me. 1:1 coaching is available for personal and organizational/team growth topics. I help you become a high-performing leader 🚀.
Promote yourself to 24,000+ subscribers by sponsoring this newsletter.