Airbnb recently detailed how it designed and built a unified architecture for collaborative hosting. This architecture streamlines the development process of new products, as engineers only need to know about one central framework that will cover all hosting use cases. This framework encapsulates the specific types of collaborative hosting, freeing the engineers from the need to worry about them.
Initially, a single host (person) managed each property. Later, Airbnb introduced co-hosts since hosts often share their responsibilities with another trusted person, such as a family member or a neighbour. 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 collaborative Hosts grows and new forms of collaboration get introduced, the engineering work to support them becomes increasingly complex." She summarises the motivation for encapsulating these business requirements:
Engineers who are building a new feature need to understand all of the existing types of collaborative hosting and decide how collaborative hosts should interact with the feature. (...) Without any kind of unifying framework, product development for hosts can quickly become a laborious process.
In a single host model, engineers could easily store the host id on each listing to determine who has permission to act on that listing. This permission check might look like the following:
if (isListingHost) {
// Take action on the listing
}
Once Airbnb added new forms of collaborative hosting such as co-hosting and teams, this code becomes unwieldy. Permissions checks accross the codebase might start look like the following:
if (isListingHost ||
isListingCoHost ||
isListingTeamMember ||
isListingCollabHost1 ||
isListingCollabHost2 ||
...) {
// Take action on listing
}
In the new framework, Airbnb uses "user groups" to represent any 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.). Then, a central location is responsible for maintaining all associations between user groups and resources in the system (listings, reservations, etc.).
Source: https://medium.com/airbnb-engineering/how-airbnb-supports-co-hosting-edfb11d88575
An event triggers the system to update the relevant associations whenever a collaborative hosting relationship or resource is updated. It is important to note that this event doesn't contain details of the change. Instead, it only specifies that a change to a specific resource or group has happened, along with their id. The system then fetches the data and calculates the correct associations in an eventually consistent manner.
Source: https://medium.com/airbnb-engineering/how-airbnb-supports-co-hosting-edfb11d88575
Handling the events in this manner allows Airbnb engineers to optimize performance by parallelizing and batching updates. In addition, since each resource update event triggers a re-calculation of associations that is agnostic to the specific type of update, the entire update process is idempotent.
Given that 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 created several patterns to allow developers to query permissions for a specific action, allowed resources per user, and allowed users per resource to simplify development further. These patterns include the usage of Himeji to query permissions and ElasticSearch to join the user to resource associations with the resource data for easier querying.
