almessadi.
Retour aux projets

Étude de cas projet

Stats-Coronavirus_

Création d'un tableau de bord et d'une API de suivi du COVID-19 axés sur une livraison priorisant le cache, une faible complexité opérationnelle et une résilience face à des pics de trafic mondial intenses.

Le Problème

Au début de la pandémie, le problème de l'information était évident : les gens avaient besoin d'un endroit rapide pour vérifier l'évolution des chiffres de cas sans attendre des tableaux de bord lents ou des API surchargées. Cela signifiait que le système devait privilégier la résilience et les performances de lecture au détriment de l'élégance architecturale.

L'Architecture

La conception était intentionnellement simple sur le chemin critique. Les données étaient extraites de sources publiques, normalisées lors de l'ingestion, puis poussées dans Redis afin que la couche de lecture puisse servir des réponses précalculées au lieu de les générer à la demande.

Le frontend React était principalement axé sur la présentation, tandis que l'API se comportait davantage comme une couche de livraison de cache que comme un backend d'application traditionnel.

Ce Qui Comptait Techniquement

  • normaliser une fois lors de l'ingestion au lieu de calculer à chaque lecture
  • garder Redis sur le chemin critique pour des recherches rapides
  • éviter des pièces mobiles inutiles lors d'un événement de trafic mondial
  • servir un frontend qui pourrait rester statique et ami du cache

C'était un cas où la simplicité était le mouvement avancé. En cas de trafic extrême, moins de pièces mobiles l'emportent souvent sur une architecture plus sophistiquée.

Cette leçon demeure. Si le chemin de lecture doit résister à une attention publique inhabituelle, le précalcul et la discipline de mise en cache comptent plus que l'ornement architectural.