Airbnb recently detailed how it designed and built a unified architecture for collaborative hosting. This architecture streamlines the new product development process because engineers only need to know one central framework that covers all hosting uses. This framework covers the specific forms of collaborative hosting, giving the technicians nothing to worry about.
Initially, a single host (person) managed each property. Airbnb later introduced co-hosts, as hosts often share their responsibilities with another trusted person, such as a family member or neighbor. Today, Airbnb hosting is the primary occupation of many hosts acting as part of a business. These users manage teams of other users and associated roles for each of them.
Angeline Rao, an engineer at Airbnb, states that “as the number of collaborating hosts grows and new forms of collaboration are introduced, the technical work to support them becomes more complex.” She summarizes the motivation for encapsulating these business requirements:
Engineers building a new feature need to understand all existing types of collaborative hosting and decide how collaborative hosts should handle the feature. (…) Without any unifying framework, product development for hosts can quickly become a tedious process.
In a single host model, engineers can simply store the host ID on each entry to determine who has permission to respond to that entry. This permission check might look like this:
if (isListingHost) // Take action on the listing
Once Airbnb adds new forms of collaborative hosting, such as co-hosting and teams, this code becomes impractical. Consent checks in the codebase might look like this:
if (isListingHost || isListingCoHost || isListingTeamMember || isListingCollabHost1 || isListingCollabHost2 || ...) // Take action on listing
Under the new framework, Airbnb uses “user groups” to represent each group of people. An ID, a group type (co-hosting, team, etc.), and a list of members define each group. Each group member is associated with a role within that group (owner, co-host, etc.). Subsequently, a central location is responsible for maintaining all links between user groups and resources in the system (lists, reservations, etc.).
An event triggers the system to update the relevant links when a collaboration hosting relationship or resource is updated. It is important to note that this event does not contain details of the change. Instead, it just specifies that a change has happened to a specific resource or group, along with their id. The system then retrieves the data and calculates the correct associations in a consistent manner.
By handling the events in this way, Airbnb engineers can optimize performance by parallelizing and batch-bundling updates. In addition, since each resource update event triggers an association recalculation that is agnostic for the specific type of update, the entire update process is idempotent.
Since this system is in place, developers do not need to know the specifics of collaborative hosting. Instead, they can rely on the data in this single location to understand the relationship between a specific user and resource.
On top of this system, Airbnb has created several patterns that allow developers to request permission for a specific action, allow resources per user, and allow users per resource to further simplify development. These patterns include using Himeji to query permissions and ElasticSearch to associate the user with resource associations with the resource data for easier querying.