Comment une petite équipe a transformé l’architecture d’un service de streaming

Chez LesNews, nous revenons sur la refonte progressive d’une plateforme de streaming menée chez ProSiebenSat.1 — un acteur média européen reconnu pour son audace opérationnelle — qui illustre bien les choix techniques auxquels sont confrontés les services vidéo à grande échelle. L’expérience montre qu’aucun manuel miracle n’existe : tout se construit par itérations, compromis et automatisation.

Il y a un an et demi, l’équipe en charge de l’application Joyn (marché DACH) devait monter en charge pour des audiences internationales. La plateforme subissait des pics de charge réguliers, la base de données était un nœud unique sans cache, et la cohérence des données variait selon les services. Face à ces limites, deux développeurs sans expérience AWS ont engagé une refonte par étapes : suppression des SPOF (single point of failure), migration vers des services managés, introduction d’un modèle event-driven et mise en place d’une stratégie multi-région progressive.

Rendre les données fiables : hub-and-spoke et claim check

Le cœur du problème tenait à l’hétérogénéité des validations et des transformations : plusieurs services consommaient le même topic Kafka mais n’appliquaient ni règles ni standards communs, entraînant des incohérences observables par les utilisateurs. La solution retenue a été une architecture « hub-and-spoke » (ou « bus mesh ») fondée sur :

• Kafka comme magasin d’événements primaire.
• EventBridge pour le fan-out et l’abstraction d’interface entre services.
• EventBridge Pipes pour intercepter, valider et enrichir les messages avant distribution.

Pour gérer les gros payloads typiques du streaming (méta-données volumineuses, assets), l’équipe a adopté le pattern « claim check » : les payloads lourds sont stockés dans S3, EventBridge ne transporte qu’une clé (pointer) et les consommateurs récupèrent les données au besoin. Ce choix réduit la charge réseau sur le bus d’événements et permet d’offrir une API qui scale sans développement d’infrastructure sur mesure.

Réplique vs. événements

Alternativement, la réplication de base (pglogical sur Postgres) reste une option valide selon les besoins : elle normalise les données dans une base unique mais introduit une forte dépendance au SGBD et complexifie les évolutions de schéma. L’architecture événementielle, elle, favorise le découplage et la recomposition des données côté consommateur (Aurora, DynamoDB, fichiers…). Le choix dépend de la stratégie d’opération et des contraintes métiers.

Serverless et bonnes pratiques d’ingénierie

La migration vers du serverless n’a pas été motivée par le fashion tech, mais par la volonté de déléguer l’exploitation pour que l’équipe se concentre sur le code métier. En tirant parti des services managés (Lambda, EventBridge, DynamoDB/Aurora Serverless, S3, CloudFront), la scalabilité devient automatique et les temps de déploiement sont passés d’1h30 à quelques minutes.

Mais l’infrastructure seule ne garantit rien : il faut appliquer les bonnes pratiques (timeouts, retries, circuit breakers, caching, observabilité). Par exemple, Lambda + API Gateway n’est pas nécessairement le couple offrant la plus haute disponibilité ; un Application Load Balancer combiné à Lambda peut parfois fournir des garanties opérationnelles supérieures selon les SLAs visés.

Sélection des bases et stratégie de cache

Le choix du stockage reste délicat. Les bases serverless (DynamoDB, Aurora Serverless) simplifient grandement les opérations. En revanche, Aurora/RDS impose une gestion de VPC et de sous-réseaux, qui complexifie la réplication multi-région.

Pour réduire la dépendance à la base et les coûts, l’équipe a mis en place une stratégie de cache en plusieurs couches :

• CloudFront à la périphérie pour l’edge caching.
• Cache en mémoire local dans les instances Lambda/Fargate pour les hot keys.
• Momento (service cache managé) devant la base pour le reste.

Résultat : la charge sur la base est descendue sous les 10 % pendant les heures de pointe, rendant possible des clusters plus modestes et ouvrant la voie à des configurations multi-région économiquement viables.

Cell-based et multi-région : réduire le blast radius

Avant de dupliquer toute l’infrastructure, l’équipe a adopté une architecture en « cellules » : découpage du trafic par pays (Allemagne, Autriche, Suisse), par type d’utilisateur (payant / gratuit) et par plateforme (iOS, Android, web, TV connectée). Ce partitionnement multiplie la capacité concurrente et réduit le périmètre affecté par une défaillance.

La logique : au lieu d’un seul Lambda servant tout, on déploie plusieurs fonctions identiques mais isolées. Si une cellule rencontre des limites, les autres continuent d’opérer. Ce pattern facilite aussi les déploiements progressifs et les tests ciblés.

Automatisation et coûts multi-région

La vraie résilience requiert une réflexion honnête sur les coûts : la multi-région multiplie les besoins de réplication et les transferts de données. L’approche retenue a été progressive — préparer chaque service à une stratégie multi-région (backup & restore, pilot light, warm standby, active-active) puis n’activer que ce qui est nécessaire.

Plusieurs optimisations ont rendu la multi-région plus abordable :

• Remplacer API Gateway par un Application Load Balancer pour réduire les coûts de routage (avec gestion CORS côté code).
• Basculer dynamiquement entre Fargate et Lambda selon le profil de trafic : Fargate coûte souvent plus cher sous un certain volume à cause du coût fixe des containers, tandis que Lambda offre une capacité instantanée pour les pics.
• Automatiser la surveillance et les bascules (ALB, Route 53, alarmes CPU/mémoire) pour déclencher des actions sans intervention humaine.

Points à retenir

• Utiliser un pattern hub-and-spoke (Kafka + EventBridge) clarifie les frontières entre services et améliore la cohérence des données.
• Le pattern claim check (S3 + EventBridge) permet de transporter des clés légères et de stocker les gros payloads, évitant de surcharger le bus d’événements.
• Découper l’application en « cellules » (pays, type d’utilisateur, plateforme) réduit le blast radius et multiplie la capacité concurrente sans complexifier le développement.
• Une stratégie de cache multi-couches (edge CloudFront, cache en mémoire, cache managé) peut faire chuter l’usage de la base à moins de 10 % en heures de pointe.
• Automatiser la surveillance et les bascules (Fargate ⇄ Lambda, Route 53, ALB) est crucial pour rendre la multi-région économiquement viable et limiter l’intervention humaine lors des incidents.
• Le choix entre réplication de données et architecture événementielle dépend des priorités : indépendance des services versus simplicité d’un schéma centralisé.
• Les décisions techniques doivent être traduites en compromis clairs pour les dirigeants : la résilience a un prix, et c’est une décision business autant que technique.

Pour ma part, ce récit illustre une conviction : rendre une plateforme résistante et évolutive ne se fait pas par effet de manche, mais par une série de choix pragmatiques, mesurés et automatisés. Je pense qu’il faut rapprocher davantage les discussions techniques des arbitrages financiers et métiers — quand les équipes présentent des options claires, la décision devient partagée et responsable. Et vous, quelles priorités mettriez-vous en tête pour la prochaine refonte d’un service critique ?