Notifications started as a simple way to alert LinkedIn members when something important to them happened on our network. However, as the range of activities and actions available to members increased, so did the use cases and sheer volume of notifications. It became clear that we needed a new technical architecture for notifications that would let us scale from serving just a handful of notification types—owned and maintained by a single team—to an end-to-end platform serving potentially hundreds of notification types—owned and maintained by dozens of partner teams.
In this post, I share details about how we at LinkedIn tackled the challenge of transforming notification development from a one-off process to a standardized, platform-centric approach. With this transformation, we had to rethink how we spec and design a new notification, how we architected the frontend and how we modeled notification data in the backend.
Notification creation challenges
Initially, all notification work was custom. A partner team requesting a new notification had to create a product spec and design for the notification from scratch. The engineering effort involved six systems: a notification producer, the Notification Service, the front-end API, and three clients—Android, iOS, and web. Additionally, an engineer was required to design a new model schema for the notification type and to pass the new schema through our model review committee.
All in, about 12 weeks of engineering effort was required to launch a new notification type across four engineering specialties: apps, Android, iOS, and web. It was occasionally more challenging for teams to meet the skill set requirement than the total level of effort, because not all teams at LinkedIn have mobile specialties. Due to the effort and skillset required, several instances occurred where a notification that would have provided value to our members was delayed or outright abandoned.
Beyond the challenge of launching new notifications types, the lack of a cohesive platform was an impediment for the Notification Team when it came to maintaining and advancing the product. For example, when we saw strong results in an experiment to add a call to action to a notification, the steps needed to retroactively implement calls to action for all existing notifications required significant effort.
Project One: creating a notification framework
The Notification Team recognized the need to create a formal platform. We called this technical rearchitecture Project One, because our goal was to enable one engineer with an apps skill set to launch one new notification type in one day of effort. We recognized it was ambitious to try to reduce development effort from 12 weeks to one day, but we also knew that even partial success would be a dramatic improvement.
We knew the path forward required reducing the number of systems involved to onboard a new notification type from six systems to just one. There were three main bottlenecks we would need to work through to be successful:
- While the current notifications were almost visually consistent, we needed a standardized design system for all notifications to follow.
- We needed to implement the notification formatting logic in a single system to remove the need for per-notification client work.
- We needed to define a generic notification schema to pass notification data from the producers through the various systems without having to touch each of those systems for every new notification.
Working through the bottlenecks
The first bottleneck was the easiest to work through, as product and design jumped at the chance to increase consistency between notifications. We worked closely with design to create a notification design system based on reusable components. We defined a set number of content areas, such as headline, entity image, content, and call to action, and a set number of components that could be used in each content area, such as a content section that could have some combination of primary text, an image, and supporting text.
For the second bottleneck, we were lucky in that we weren’t the only team interested in enabling fast-paced development at that time. Our mobile infrastructure team was independently working on defining a better way to model front-end APIs. At the time, our front-end API primarily provided data-based models and required the clients to separately translate the API data model to a view model for use in view layer code.
The new approach we jointly developed is called Render Models, and it works by sending view models directly from the front-end API—but with a slight twist. When data needed to remain consistent, like a member name or profile image, Render Models included that data model and referenced it from the view model. We collaborated with the Mobile Infrastructure team to pilot Render Models for notifications, enabling us to completely remove client-side development as a requirement to launch a new notification, as well as building utilities to efficiently work with Render Models when creating new notifications.
For the third bottleneck, we used existing notification schemas as a baseline to model a new generic notification schema that holds all of the information needed to create, process, and format a notification. This was largely possible due to LinkedIn’s distributed architecture. We did not need the generic schema to store all possible notification data; instead, downstream systems store most of this data, referenced by Uniform Resource Names (URNs). At format time, we use these URNs to decorate the full notification data.
Notification producers all produce to the same Kafka topic with this new generic schema to request the creation of a new notification. We gave the Notification Service the ability to store, aggregate, and retrieve a notification generically from these creation requests. We were hoping to completely remove the Notification Service as a touchpoint to onboard a new notification; however, in the end, the system we developed requires partner teams to add a single line of code that associates a notification type with its method of aggregation. We built three methods of aggregation to make this aspect of the process easier.
Platform enhancements
The ambition of Project One inspired other teams to help out. The Relationships Team enhanced its notification producer by creating a platform called Beehive that can quickly produce a new notification type for any team from any offline data. Similarly, the Feed Data Platform Team and Relevance Team jointly created Concourse, a new platform to enable the quick production of new notifications from online data. With Beehive and Concourse, partner teams no longer need to create and maintain their own notification producers and can instead simply use one of these two platforms, depending on their data need for offline versus online data.
We needed to ensure our members would not be overwhelmed by the new notifications our platform would enable, so we introduced the Air Traffic Controller (ATC) service as a permanent gatekeeper and filter for all new notifications. ATC is designed to manage the frequency and channel selection of external communication to our members. Our new solution treats in-app notifications as another communication channel, and enables us to send only the most relevant notifications to our members.
Reducing the effort twelvefold
With Project One, Beehive, and Concourse, we reduced the touchpoints to onboard a new notification from six to three, completely removing the need for any client-side effort. We changed the need to create a new notification schema to needing to simply define a new notification type. Overall, the effort required to implement a new notification was reduced from 12 weeks to just one week. While we did not reach our ambitious goal of one day, we are proud of reducing the effort twelvefold.
As engineers, our job is to automate away repetitiveness. Even as a product-focused team, we’re always looking for places to streamline processes and simplify tasks. To be members-first, we realize the importance of removing the friction that prevents our team and partner teams from creating valuable member experiences as quickly as possible.