Spotify est un système de streaming musical. Il permet aux utilisateurs de parcourir un catalogue de chansons et de podcasts, puis de lancer la lecture audio sur leur appareil.
La promesse fondamentale est simple. Lorsqu’un auditeur appuie sur le bouton de lecture, l’application doit démarrer le son rapidement et assurer la continuité de la lecture, même lorsque le téléphone passe d’un réseau mobile puissant à un réseau faible.
Avant de passer à l’échelle, la version la plus simple consiste en une application cliente communiquant avec un backend unique. Ce backend répond aux requêtes concernant le catalogue (artiste, album, durée du morceau) et fournit également les données audio pour la lecture.
Cette configuration de base comprend une base de données pour les métadonnées et un système de stockage d’objets pour les fichiers audio. Sans CDN, sans répliques ni files d’attente, chaque demande de lecture dépend de la disponibilité et de la rapidité de ce backend unique. Voici une représentation globale de cette configuration de base :
Dans le schéma, le client mobile envoie des requêtes via Internet à un serveur d’application unique. Ce serveur lit les métadonnées du morceau dans la base de données correspondante et récupère le fichier audio depuis le système de stockage d’objets, puis diffuse le flux audio vers le client via la même connexion. En l’absence de couches intermédiaires, tout ralentissement au niveau du serveur d’application, de la base de données ou du stockage d’objets se traduit immédiatement par un démarrage plus lent ou des saccades lors de la lecture.
Pour ce cours, le périmètre fonctionnel reste restreint. Un auditeur peut parcourir le catalogue, effectuer une recherche simple et lancer la lecture d’un contenu audio ; le système doit alors identifier le bon morceau et diffuser le flux audio correspondant.
Deux indicateurs signalent le moment où l’architecture de base (serveur unique) atteint ses limites. Le premier est la latence de démarrage au 95e centile (p95) : 95 % des tentatives de lecture doivent démarrer dans un délai cible, car une proportion importante de démarrages lents donne l’impression que l’application est défaillante. Le second concerne la lecture simultanée : lorsque de nombreux utilisateurs lancent une lecture en même temps, un pic d’activité ponctuel se transforme en une charge soutenue pour le backend et le système de stockage.
Dès que l’on fait évoluer l’architecture de base, les mêmes notions de compromis reviennent systématiquement. Elles associent un choix de conception à un résultat visible dans Spotify, comme un démarrage de lecture plus rapide, une facture cloud plus élevée ou une réduction des pannes lors des pics de trafic.
Ce tableau ancre le vocabulaire utilisé dans le processus de lecture et les opérations d’arrière-plan :