fix schema archi kafka

content/post/2023/cdm/index.md

@@ -24,7 +24,7 @@ La communication en amont avec les partenaires a été soignée : « nous leur a
 ### Une cartographie exhaustive de chaque maillon applicatif
 Outre cette large communication, chaque pan de l’infrastructure a été passé au crible pour identifier les zones à risque. La partie applicative qui combine entre autres des containers orchestrés via [Kubernetes](https://tech.tf1.fr/post/2021/architecture/eks/), un back end en Go, [des API en GraphQL](https://tech.tf1.fr/post/2020/architecture/graphql-and-persisted-queries/), une architecture événementielle adossée à [Kafka](https://tech.tf1.fr/post/2021/architecture/migration-vers-kafka/), a été largement testée. « Nous avons veillé à ce que notre pré-prod soit dimensionnée de manière iso avec notre production. Objectif : coder des scénarios pour simuler la charge au regard de nos objectifs de nombre d’utilisateurs par seconde en obtenant des évaluations précises », précise Rémy Pinsonneau, architecte.
 
-![Kafka transformer / projecteur](../../2021/architecture/migration-vers-kafka/images/archi-indexeur.svg#darkmode "Kafka transformer / projecteur")
+![Kafka transformer / projecteur](../../2021/architecture/migration-vers-kafka/images/archi-kafka-lot1.svg#darkmode "Kafka transformer / projecteur")
 
 Afin d’identifier toutes les applications externes impliquées dans la chaîne de performance, une cartographie a été dressée. « Pour la Home par exemple, nous avions listé de manière exhaustive les end points appelés afin de les mettre chacun à l’épreuve et d’analyser les effets en cascade en cas de défaillance du service. Ce travail a permis de définir le nombre de pods Kubernetes requis, mais aussi de procéder à des optimisations telles que la mise en place d’un cache in-memory ou encore la réduction des appels sur un service comme Gigya (fourni par SAP pour assurer l’authentification des utilisateurs) pour éviter de surcharger l’API ».