Engineering LinkedIn Reactions | LinkedIn Engineering

LinkedIn’s New Reactions

On LinkedIn, you can expect a “like” button to appear on every post in the feed, in every context in which a post appears. You can expect it to maintain state wherever it’s seen. You can expect it to notify the author that you liked the post, and you can expect posts with more engagement to rank higher in your feed.

The architectural reach of a “like” in the LinkedIn ecosystem cannot be overstated.  “Likes” flow through several services involving dozens of code repositories across multiple different apps. There are 27 development teams across LinkedIn with a stake in “likes.” Although the member experience may appear straightforward, the technology behind it is not.

Given this complexity, we had to develop strategies and cross-team collaboration channels in order to tackle the challenge of building out “likes” into reactions:

  • First, we had to reduce a complex engineering and UX problem to its foundational use case: reactions on feed posts. Once established, we used the foundational technical architecture and user experience with reactions as the platform to inform how it scales to the various consumers and use cases of the feature.

  • Next, in order to execute on a complex, multi-site engineering project, we had to rely on some of our core company values to effectively manage the feature.

Establishing foundations

The backend platform: Reactions data model
As a first step, we created a data model to represent reactions. Conceptually, reactions are composed of three components:

  1. An actor: Who created the reaction?

  2. An object: What is the entity that was reacted to?

  3. A verb: Which reaction was selected?

Within each of these components, we had to determine how much flexibility to design for:

  1. Although every reaction will require an actor, there are several possible types of actors (i.e., members, companies, schools, etc.). Therefore, this field should be general enough that various actor types are supported.

  2. Similarly, every reaction requires an entity. We currently only support reacting to posts and articles, but the model should not limit the types of entities to which a member can react. In the future, we may want to support reacting to comments, messages, or jobs, etc.

  3. The reaction type verb required deeper consideration. How much flexibility should we allow in terms of the types of reactions supported?

Reaction type
There are three questions that drove this consideration.

  1. How much experimentation will we want to do with the set of Reactions?

  2. Do we want to support one-off reactions (e.g., an icon added specifically for a holiday)?

  3. What do we need to do to maintain legacy “likes” for backwards compatibility, while still including them as a part of the new reactions set?

The first two questions were answered in collaboration with our product partners. We determined that we wanted to support controlled experimentation—experimentation within a predefined set of reaction types. When doing our initial brainstorm of what reactions to include in the set, it became clear that there was a finite number of broad signals we would consider as a reaction. Also, we front-loaded the experimentation without needing to build into the product; for example, we hosted a series of user studies to understand how members interpret a variety of reaction types. By the time we decided which types to explore in the product experience, it was clear that we had narrowed the set to 10 possible options.

We also determined that we did not want to support one-off reactions. Building a new reaction type has implications for the ecosystem in which our relevance model would have to understand how to interpret a new signal, and data analytics would have to update the tracking they expect for a new signal. Once we introduced a bespoke reaction, we would have to support that type of reaction forever. This has implications for maintaining the consumption experience for that icon and maintaining it in the design systems library, even as the design frameworks evolve. Given these significant ramifications, we determined that it would be too expensive to support temporary reactions.

Once we had these questions answered, we consolidated a list of 10 reaction types to be supported by the platform. The reaction type field would only accept the value of one of these 10 predetermined types, while the UI would only display five of this broader set of 10 for a member to select. This way, we could display any five of the 10 reaction types for experimentation as we finalized the set that we wanted to launch with. Knowing that we would not support one-off reactions, we were able to explicitly define these reaction types as fixed values in the data model. To learn more about the design journey in creating these reactions, please see more details here.  

So what about legacy “likes”? The reactions feature was bootstrapped with a data migration, in which “likes” were copied from an existing service to a new one that was spun up to store reactions. This enabled us to conceptualize “likes” as a type of reaction in the new database while temporarily supporting legacy “like” objects as clients iteratively migrated to the new one.

The database migration introduced significant challenges.  As a prerequisite to launching reactions, we first had to migrate all “likes” traffic to the new database.  “Likes” traffic is skewed in the sense that certain posts are really viral, so a small subset of posts drive a disproportionately high percentage of reads and writes against the database.  Because we made changes to the data structures that introduced a different pattern for reading and writing reactions, the hardware alone could no longer handle these spikes in traffic without significant degradation to the user experience.  To solve this problem, we introduced a caching layer to keep popular posts in memory. This improved our read throughput on these popular posts by serving requests from memory rather than disk.  This is just a single example among many challenges with creating the data platform for reactions.

The client platform: Reactions desktop web components
It turned out that the data model was not the only thing that needed to act as a platform; so did the UI. Members can currently react to posts on 11 different pages (including feed, search, articles, etc.), and this does not include future iterations that might introduce reactions in other contexts.

Source link