Optimize / Decrease Playlist Latency

[adambechtold]

Background

The time it takes to generate a playlist is increasing as the amount of listening history we store grows.

Number of Listeners/Users	Total Number of Listen Events	Time to Generate Playlist (median/95th percentile)
30	1.5M	0.8s / 1.5s
50	2.5M	1.2s / 4.5s

Goals

• 🎯 Goal - Playlists appear very quickly when requested by the user
• 🎯 Goal - The time required to provide a playlist is not directly proportional to the number of listening history events

Example

• ⚖️ Consideration - We timed the requests using network tools, but this demo provides a more subjective, intuitive sense of that the experience is like as a user

https://github.com/adambechtold/taste-explorer/assets/22563063/3015c9a7-4f14-4a9a-bbac-3e83573f67dd

[adambechtold]

Approach - Eagerly Generate Playlists and Store in a Cache

It is easy to predict what kind of playlists users will request. For any combination of users, there are only 3 options.

• User 1 Only
• User 2 Only
• Both

▲ Pro - Achieves 🎯 Goal - playlists appear very quickly ▲ Pro - Partially achieves 🎯 Goal - time required is not directly proportional ▼ Con - Does not decrease the actual amount of time required to generate playlists; It just hides it from a user

Variant - When a user visits the taste-comparison page, generate all 3 playlists and store them in a cache

Any time we load the taste-comparison page, create all 3 playlists. When a user requests the actual playlist, just pull it from the cache.

▲ Pro - Easy to implement ▼ Con - Does not address the case when users navigate directly to a taste-comparison with query parameters that specify a playlist

• 📍 Position - Adam: This is only likely to happen after someone has already visited the page; In which case, the playlists might still be on the cache (depending on the cache size and invalidation policy)

Variant - Every day, create all playlist possibilities, store in a cache

Run a cron job that creates all possible playlists once a day.

▼ Con - The size of the task would grow quickly ▼ Con - Does not address the experience for new users added that day

[adambechtold]

Approach - Migrate Listening Events into a Time-series Aggregation

Right now, we store each event individually and perform aggregations (counts) for every playlist generation. We may be able to reduce the number of data points if we aggregate individual events into a time-series format.

▲ Pro - Decreases the time required to generate a playlist ▼ Con - Increase data storage ▼ Con - Requires a migration

[adambechtold]

Update - PR #27 - feat: Eagerly load and cache playlists

This PR implemented the approach to Eagerly Generate Playlists and Store in a Cache using the on-page-load variant.

This dramatically increased the speed.

[adambechtold]

Update - PR #29 - feat: Show loading spinner

This PR didn't decrease latency, but it makes the experience of waiting easier because it's clear something new is coming.