Spotify Modernizes Client-Side Architecture to Accelerate Service on All Devices

Engineer Carl Engström explains how lifting the 10,000 limit on Liked Songs enabled his team to address a much deeper issue and improve the listening experience of end users, whatever their device or network. 

At first glance, lifting the 10,000 limit on Liked Songs seems like a simple engineering exercise. Some Reddit commentators even claimed to have identified a few lines of code that set the restriction. Why not just delete them and tidy up any gaps?

As the old saying goes, ‘it was a bit more complicated than that’. To understand why, we must dig deeper into the history of the Spotify technology stack, especially the client-side desktop and mobile layer that dominate the user experience.

Our client architecture is designed to be simple and dates from a time when laptops dominated the listening experience. This helps, especially in the early days, when you measure what works, and what doesn’t. If a feature doesn’t hold up, we can then replace it with a more sophisticated system.

Liked Songs, one of Spotify’s most popular features, is a great example of this approach. Every time you open the Spotify app, it loads all the metadata associated with these tracks from the device’s disc storage into the active memory (RAM).

Simple, right? Not necessarily. If you collect thousands of Liked Songs, every time the app starts, all that metadata (including artist name, paths to album artwork, and so on) must be loaded from scratch. That’s fine if you’re using a laptop, or the latest smartphone because there’s enough RAM to manage this step with minimum delay. (Laptop users generally benefit from stable wireless connectivity, which also speeds up the process.)

But we now live in a technologically diverse world. Spotify listeners are increasingly mobile, which means that the smartphone Home page plays a greater role in the user experience than the Library, where Liked Songs resides.

It’s also thirteen years since the launch of the first smartphone. Today, there are thousands of different devices. This presents another challenge. How do you deliver an outstanding user experience to all Spotify listeners when there are such disparities in device processing capacity and network connectivity?

A better listening experience for all

Our previous architecture made it simple to observe the Liked Songs success rate at startup. Either all the metadata loaded successfully, or it didn’t. We could also measure how long this took, and how many people hit, or were close to hitting, the 10,000 limit.

Over the past two to three years, we noticed that the startup experience for those with less powerful devices and weaker connectivity wasn’t ideal, especially when they were near or at the 10,000 limit. We also discovered that even if a listener had thousands of such tracks, they generally only listened to a few hundred.

For both of these reasons, we decided to act. It’s important to remember that now the goal wasn’t just to lift the 10,000 limit. That was the tip of the iceberg. Rather than simply focusing on the limit itself, we found a much larger opportunity: modernizing our client-side architecture, thereby addressing the needs of our entire demographic, especially those with older phones and access to slower networks.

The solution: Modernizing the technology stack for a global audience

We addressed the challenge from two perspectives. First, could we find a way to avoid loading all the metadata on a given device every time the user opened the app? Second, when we initiated that download, could we do so in batches that minimized startup and view-load times? In April of this year, we were ready to test this approach for iOS  and then for Android.

How does it work? The first time you open the app with the new client, Liked Songs metadata downloads in batches to your smartphone. The data is then stored on the drive of your device or an SD card if necessary.

Crucially, we also pre-create all the sortings available with Liked Songs (by title, artist, album and recently added) and store them on disk. Now we can show any view by reading the correct table and streaming the pre-computed results from disc storage. This replaces the previous method where sorting took place in memory, restricting the speed of less powerful smartphones.

From then on, every time you fire up the app, the metadata is already there, along with all your Liked Songs, sorted and ready to use. The app also checks Spotify servers for new likes and corresponding metadata is added to the device.

Our testing shows a considerable improvement in startup and view-load times, especially with less powerful smartphones. This reflects a desire at Spotify to better serve all our customers, especially those with older phones and less reliable connectivity.

And even if you’re not a Liked Songs power user, overall performance improvements may result in more enjoyable listening experience.

From research to release: Like changing the engine in mid-flight

Historically, Spotify has taken an iterative approach to improving the tech stack. But as our research showed, this wasn’t an option with Liked Songs.

That’s why we needed a year to complete the project from research to release. To modernize the client architecture we had to remove or modify about 100,000 lines of code in the shared client code base. Some of these required several additions, adding to the complexity. We also tweaked both the Android and iOS apps.

At every step of the build, we had to ascertain that our new version replicated existing application features in their entirety — the classic software engineering equivalent of ‘changing the engine in mid-flight’.

During the research and preparation of technical specifications, there was an enormous amount of ground to cover. For example, where and how can a listener ‘like’ a song exactly? There are dozens of ways of adding to Liked Songs in your library. We had to identify every single one and map the process to our new architecture.

In parallel, we had to track enhancements to the operational client architecture and bake these iterations into our own code, so that features and functionality were identical when we switched over.

A lot of work also went into matching the evolution of the overall user experience and user interface. We worked closely with those teams to make sure the new architecture supported overall trends on the Home page. The recent addition of Shortcuts is a good example of the shifting user experience, and our approach had to support this direction.

Testing and development took place in parallel, allowing us to add more people to the test groups as the stack became more stable. About seven months before launch, we were working with 30 employees, growing to 1,000 four months later. This gave us control over the testing process, and returned plenty of unfiltered Spotify feedback on changes to the user experience!

We then added about 1% of all users, gradually increasing this figure to 50% to find those ‘one-in-a-million bugs’. This enabled us to complete any remaining fixes before switching all users over to the new architecture.

The prioritization puzzle

I’m often asked, how do you decide to green-light a project, such as this, when there are so many competing priorities? It’s a good question that goes right to the heart of how we make complex and difficult resourcing decisions at Spotify.

I’d been monitoring the impact of the likes threshold for about three years. I knew that if we just lifted the limit this could have a negative impact on the overall experience of our end users. And at that stage, we didn’t know for sure if it was worth investing in an overhaul of the architecture to accommodate this one enhancement.

But when we looked at wider changes in user behavior, our attention ultimately shifted from lifting the limit to improving our tech stack benefiting users for years to come.

This also forced us to rethink our approach to audience segmentation. Sometimes, organizations with hundreds of millions of users and huge datasets can lose sight of the individual. It’s very easy to imagine that the average Spotify listener has the latest smartphone or similar, but of course they don’t. Our approach has definitely shifted in favor of more segmented analyses that better serve the entire device-connectivity spectrum.

There was also a strong motivation to ‘do the right thing’ on behalf of end users worldwide. For all the talk of technology stacks and like limits, we always keep in mind what’s important at Spotify, which is to give our listeners the opportunity to enjoy and be inspired by music and podcasts.

Finally, I’d like to thank everyone on the team who made such an important contribution throughout the project, including Felipe Oliveira Carvalho, Marcus Fredriksson, Niklas Björnberg, Oscar Andersson, and Marcus Vesterlund. Listening to music is a universal pleasure that connects people across countries and cultures, and I was proud to be part of a team that helped deliver a better listening experience to as many people as possible. Well done to all of you for keeping the plane in flight throughout!

Tags: Data