Groups

Rebuilding the Groups Experience on LinkedIn

Co-authors: Pujita Mathur, Dylan Gattey, James Ging, Shane Hill, Kelly Hosokawa, Kyle Huynh, Gevorg Kurghinyan, Navya Sruti Sirugudi, and Louis Xu
 

The vision of LinkedIn Groups is to help the world’s professionals advance their careers by engaging in quality conversations within trusted professional communities.

Groups is a microcosm of the overall LinkedIn experience. It has its own feed of posts shared by group members. It has notifications that help provide timely information and drive engagement to the product. Members can also view and grow their network within the group through search and messaging. From an engineering perspective, Groups has a lot in common with the main pillars of LinkedIn: profile, network, feed, notifications, search, messaging, and settings.

When Groups was initially built over a decade ago, there wasn’t enough shared infrastructure between these pillars. At the time, the Groups team decided to build all functionalities custom to Groups in order to move quickly. As the company grew, the main LinkedIn product and the technology supporting it evolved to provide capabilities that previously wasn’t available. We invested in creating robust platforms which provided standardization and made onboarding new use cases easier and faster.

Building a standalone system served Groups well back at its inception. But as LinkedIn evolved and became more standardized, we realized that it was time to overhaul the Groups experience in order to realize it’s vision. We settled on the following guiding principles while rebuilding Groups:

  • Use LinkedIn’s existing infrastructure: We wanted to avoid repeating ourselves by leveraging the platforms LinkedIn has built over the past few years, rather than creating an isolated system.

  • Develop clear separation of concerns: The previous incarnation of Groups was built as a monolith. As it grew, the codebase became increasingly difficult to maintain and understand. This time, we wanted to follow a service-oriented mindset, with a clearly defined separation of ownership and responsibility. Separating the business logic into multiple microservices would help keep the code well-organized and maintainable.

  • Provide a consistent, integrated member experience: LinkedIn is constantly evolving and its look and feel have changed over time. We wanted to design the new Groups experience to cohesively fit into the overall LinkedIn experience so that members could easily participate in their Groups.

We started with researching all the technology platforms and services available to us within LinkedIn to support the use cases for Groups. We quickly realized that we could reuse or enhance existing systems to support Groups. In this post, we will share some of the benefits we saw as a part of this engineering decision to re-integrate with LinkedIn technology.

groups2
groups3

Groups backend

As illustrated in the diagram above, the Groups team previously built and maintained its own data stores, services, platforms, and code for all Groups functionality across pillars. Now, by integrating with other platforms on LinkedIn, the team only manages Groups-specific business logic within those platforms. This reduces our operational costs while allowing us to benefit from the evolution of those platforms.

Better separation of concerns
With this architecture, we were able to reduce the number of services owned by the Groups team from nine—spread across 52 software codebases—to three. Out of the three, two are brand new microservices for Groups metadata and membership. We were able to do all this while creating a cleaner separation of concerns, one of our guiding principles.

This translated into big productivity wins for the team. Onboarding new engineers became easier because they did not have to learn about legacy systems that were disorganized and hard to understand. From an operational perspective, the Groups team only owns and maintains services and data stores unique to the Groups use case (Groups metadata and membership). All other infrastructure is maintained by the respective platform teams. For example, while the Groups team owns the business logic for how to decorate a group post, we are able to leverage the Content Experience team’s expertise in maintaining and improving the content ecosystem at large.

Technology upgrades
We took this opportunity to upgrade to the latest LinkedIn technologies. We have been able to move to the latest dependency injection systems and do away with outdated libraries. Our data stores for Groups data are moving from Oracle to Espresso, which has been standardized within LinkedIn. This enables us to scale more effectively.

Feed integration

Due to our previously diverged architecture, Groups always had to play catch up for any new features introduced in the LinkedIn feed. For example, members could share videos on the feed but not in Groups without the Groups team building and maintaining the identical functionality. With the redesign, we were able to vastly improve the member experience by integrating with the LinkedIn feed’s tech stack. Here are some benefits we were able to realize as part of this integration:

Consistent user experience between the LinkedIn feed and Groups
The new Groups feed experience offers the full gamut of feed functionality out of the box and will continue to do so with little or no effort for upcoming features. Group members on mobile and web will get to post and consume all of the rich content supported by the main feed. Groups users can now post videos, post multi-photo updates, edit their posts, and reply to comments. Going forward, new features you see on the main LinkedIn feed will appear in Groups too, providing a consistent product experience to our members.

Distribution in the LinkedIn feed
Previously, Groups content (posts, likes, and comments) had a different backend service and data store than the main feed content. Both of these lived in their own silos, with limited interaction. While a post within the Groups UI was served by the Groups backend, distributing that same post within the LinkedIn feed was more complex. It required us to maintain Groups-specific logic across the core LinkedIn stack to handle Groups posts differently. We replicated social gestures (likes/comments) between the Groups and feed ecosystems. This system was fragile and prone to data synchronization issues, often causing inconsistent experiences for our members.

With the redesign, Groups content leverages the singular content platform and store that serves the main feed content. This has simplified the data synchronization complexities and we’ve been able to deprecate Groups-specific code branches that arose from the siloed architecture. This integration with the content platform enabled the LinkedIn feed’s AI to start surfacing relevant updates from your favorite groups in the main feed.

Content quality
Eliminating spam and low-quality content is something that has always been a goal for Groups team. Although we have previously built several solutions to combat this issue, we have never been able to easily leverage technology advancements in this area across LinkedIn due to our fragmented architecture.

With the current architecture, Groups is now able to leverage the same spam and low-quality classifiers that help keep our LinkedIn feed relevant and professional using the Universal Content Filtering (UCF) platform. This architecture allows us to benefit from any future improvements made in this domain with little to no effort.

Notifications integration

Previously, Groups notifications were produced and sent in a silo, unaware of any other notifications the member was receiving from LinkedIn. Email was the primary channel for notifications. This led to members dissatisfaction with excessive and non timely notifications.

In the past few years, LinkedIn has made huge improvements in our notifications platform to put members first. Concourse adds richer targeting and relevance to notifications and ATC does intelligent channel selection and delivery time optimization, etc.

The new Groups product leverages this notifications platform to deliver a consistent experience across LinkedIn by sending relevant and timely notifications. Content creators can now focus solely on getting their message out and not be distracted by how it’s delivered. They can rely on the platform to deliver it to members via a channel that’s most optimal for them (push, in-app, email).  

App consolidation

The Groups product did not previously have a well-integrated mobile app experience. We had a standalone iOS app and a web offering that were separate from the main LinkedIn app. This led the Groups experience to feel isolated from the rest of a member’s LinkedIn experience, violating our “integrated experience” principle. In order to unify the product experiences for our members, we rebuilt the Groups product across all platforms within the core LinkedIn mobile apps and website.

groups4
groups5

Enhanced admin experience on mobile
Admin tools for Groups were particularly limited on mobile. Previously, admins were unable to view and search categorized lists of members unless they were on web. Now, group owners and managers can see lists of requested, invited, and blocked users, as well as all other group admins. They can easily perform admin functions, including editing group information, promoting/demoting members and managers, transferring ownership of their groups, and approving requests to join. Additionally, we made it possible for members to create new groups and invite other members to new and existing groups from their mobile devices. With these changes, we’ve achieved feature parity with our web admin experience.

Enhanced web experience
We moved away from our standalone web offering and merged Groups with the main LinkedIn desktop application. This was a technology upgrade from play-dust to Pemberly. As a result, we were able to benefit from performance improvements built into Pemberly.

By being part of this Single Page Application, Groups is now seamlessly integrated with other LinkedIn experiences, like search, feed, notifications, etc. We are also able to leverage reusable UI components so that we have less code to maintain and can achieve the same look and feel across LinkedIn.

Developer productivity
The previous Groups experience was built before the redesign of LinkedIn mobile and desktop apps. Since then, there have been new best practices, learnings, and paradigms that Groups has been able to leverage as a result of folding into the LinkedIn flagship application. These best practices and paradigms provide a level of standardization in code across the multiple pillars of the application. For example, an Android engineer working on feed can easily understand and debug Groups code and vice versa. This is a big win for developer productivity on each platform. Engineers across teams are able to collaborate, share learnings, and work more effectively through code reviews. This also makes it easier for new engineers to quickly pick up on the best coding practices for a given platform.

We are also able to benefit from all the standardized tooling and infrastructure that is built for each platform. We get operational support in dealing with production issues and 3x3 deployments by being part of the larger Voyager community. This creates an environment where the engineers are able to focus solely on their development work and have a shared sense of ownership of the platform through the larger on-call process.

Next steps

Rebuilding all the Groups functionality in such a short time frame would not have been possible without all these robust platforms. Integrating Groups with core LinkedIn platforms has been a massive undertaking that has laid a solid foundation for future enhancements and feature development. This is just the beginning; look for more updates to the LinkedIn Groups experience in the upcoming months!

Acknowledgements  

Rebuilding the Groups experience was a multi-team collaborative effort involving several organizations across LinkedIn. Special thanks to the Content Experience, Feed Infra, Feed AI, Notifications, Search, Settings, and Trust and Safety teams, as well as all the other supporting teams that helped make this a reality.

Topics: Groups


Related articles