Evolving Search as a Platform at Wynk
Introduction
Wynk Music recently rolled out Search 2.0 - a fresh architectural design of our search backend that takes search from being a mere service to becoming a robust platform.
In this blog, we provide an overview of its key components and how they come together to help millions of users find their favourite tunes every day.
Motivation
Traditionally, search at Wynk had been a simple microservice responsible for fetching and returning relevant results in response to users requests.
In the previous system, the search microservice had a straightforward flow: it received a user request, performed some initial processing and cleaning of the request, retrieved search results as per the business logic, and then adjusted the retrieved results based on heuristics and collaborative filtering scores.
This design worked reasonably well when the system’s criteria of relevance was primarily driven by text matching, item popularities and reranking based on collaborative filtering (CF).
However, with time, our definition of relevance grew to include more nuanced signals like query features, user features, cohorts based on user features, joint features of these and many more. Even our data sources expanded as we began including more than just the catalog to generate search results. This included sources which leveraged query consumption, user consumption and several other factors.
We were also faced with a need to address segmentation use cases, which involved customising the retrieval logic based on specific parameters of the input request, whether related to the user or the query itself.
Incorporating these requirements seamlessly into our previous search system proved to be a complicated task which engendered a need for a new architectural design within which search needed to evolve as a platform.
The goal was to create a system that could seamlessly accommodate these requirements, while at the same time prioritising performance, resource efficiency and customisability while also ensuring that it could support the search for XStream OTT later.
Architecture of Search 2.0
The new architecture is designed to evolve search as a platform rather than as a service where each component is decoupled from others and is independently managed, deployed and iterated upon for improvements.
We now present a broad overview of its components.
1) Data Sources
We begin by taking a dive into different data sources which come together to return the results for a given query. The quality of search results can only be as high as the quality of these data sources so it’s important to maintain a high standard for data within these sources.
a) Content Catalogue: This is the primary source of data as it stores the catalogue of all songs, artists, albums, playlists and podcasts that we have available. This was the only data source used by the old search service.
A full-text search query is fired on this catalogue to reduce our tens of millions of documents to a more manageable subset which is later passed on to other systems for ranking and re-ranking. This filtering process is crucial as it brings out maximum number of relevant documents during the initial phase for maximum recall while the precision of the result set is taken care of by subsequent downstream systems.
b) User Consumption Persona: We capture anonymized user events on our platform from the session data pipeline which enables us to maintain the user consumption persona in real-time. This allows for a delightful personalized search experience.
Consider a scenario where a user enters the query “who” and receives the result Who Says by Selena Gomez. If the user proceeds to scroll down and listen to the song Who Says by John Mayer, their search results for the next time they enter the same query will be swiftly updated as illustrated below, typically within a few seconds.
c) Query Consumption Persona: This real-time data, sourced from session pipeline as well, is stored with the goal of providing the most frequently consumed item for a given query within recent days.
d) Knowledge Graph: Our knowledge graph (aka Catalyst) plays a pivotal role in mapping queries to similar queries and connecting them to relevant items. It serves as an intelligent resource that not only automates the process of finding related content but can also be curated manually to align with trending analysis and promotional content strategies.
e) Named Entity Recognition (NER): This is a service that acts as a data source by returning a set of results based on the understanding of the intent behind a given user query. This is useful in situations where the desired intent might not be effectively conveyed by a basic textual comparison of the given keywords. For example: queries like “80’s english rock” or “sad hindi songs”.
2) Segmentation Service
This service is responsible for determining how a given query needs to interact with other components of the search platform.
It computes the segments for the input query and dynamically decides the retrieval rules for various data sources along with the merging strategy for results from these sources.
3) Edge Service
The edge service serves as the initial entry point for search requests and plays a central role in orchestrating the request-handling process.
It first interacts with all the services in the preprocessing layer & with the segmentation service to sanitise the input query and decide the retrieval strategy, followed by interaction with various data sources and services in the post-processing layer in accordance with the rules decided by the segmentation service.
These interactions happen asynchronously and the output consists of results tuned as per the retrieval logic for specific query segments.
4) Pre Processing Layer
This layer is an abstraction for all the services that process a request before retrieval happens. The services which lie within this realm are the ones responsible for query massaging, intent extraction and spell correction.
5) Post Processing Layer
Much like the pre-processing layer, this layer is an abstraction for all the services that process the results post retrieval. This involves services responsible for tasks such as metadata enrichment, reranking of retrieved results and cherry pickling results from different sources as per the merging strategy. A few examples are as follows:
a) Learning to Rank (LTR) Service: Once the results are gathered from various data sources, they undergo further refinement through re-ranking, driven by a machine learning model which factors in intricate features tied to users, items, queries, and their associations in the results shown to the user. This model is at the heart of our LTR service which is responsible for ensuring the delivery of the most relevant results from a given set of valid candidates.
b) Meta Enricher Service: The primary function of this service is to provide metadata for given item ids. This metadata is then sent to the client, which utilises it to present results to the user for elements such as thumbnails, as an example. This service did not exist in the past because the content catalogue already housed the relevant metadata. However, as we incorporated more data sources, it became impractical for all of them to duplicate this metadata and this service was created.
Implementation Considerations
So far, we’ve broadly covered the high level design of the system. Now let’s briefly touch upon some seemingly trivial implementation considerations that have brought us non-trivial gains in performance as well as resource utilisation.
- Programming Paradigm: Our decision to go for an event driven reactive programming paradigm ensures that the requests are readily served without blocking during any of the I/O calls made for serving it. This directly translates into higher throughput or lower resource consumption depending how one wants to look at it. We used Spring WebFlux, which employs Project Reactor and Netty for non-blocking execution which brought us noticeable gains as quantified in the subsequent section.
- Communication Protocol: Server-to-Server (S2S) communication is facilitated through the reactive gRPC framework, which presents significant advantages over traditional REST communication. gRPC leverages the benefits of HTTP/2, including binary framing, and employs protocol buffers for efficient binary serialization. This reduces payload sizes, enhancing performance particularly for services with substantial payloads. The advantages become even more pronounced when multiple services are involved.
Impact
Our new architecture has been working in production for a few months now, and we have observed several positive changes, which are outlined below:
- P99 response of the service has significantly decreased by about 100 ms.
- 50% reduction in the number of pods required to handle the same volume of traffic.
- The experimental opportunities and swift iterations facilitated by this architecture have led to our north star metric CRSS (Consumption Ratio Per Search Session) being at an all-time high at about 80%.
- Seamless onboarding of Xstream OTT search.
Conclusion
This transformation of search has yielded a positive impact on the overall search ecosystem across a number of meaningful metrics and as Wynk continues to evolve, we’re committed to continually evolving our systems to bring better performance, efficiency and result quality for our users.
Credits
This project’s success is attributed to the combined work of the team that collaboratively came together to make it happen - Abhay Kumar, Ameya Dubey, Ketan Yadav, Narendra Choudhary, Pranjul Tayal, Rohit Rahul, Sidharth Negi, Sunny Meska, Utkarsh Khokhar, and Utkarsh Sopan among several others.
