À retenir
- Isoler le parcours qui encaisse l'argent de tout le reste.
- Utiliser des événements pour le travail qui n'a pas à être terminé avant de répondre au client.
- Chaque service possède ses données ; le partage passe par des événements, pas par des tables communes.
- Dès que les requêtes traversent plusieurs services, le traçage distribué est indispensable.
Quand commandes, paiements, menus et dispatch partagent une seule application, un composant lent peut bloquer le paiement. Comment une conception orientée événements isole les pannes – et ce qu'elle coûte.
Le problème des pics
La demande de livraison de repas arrive en pics abrupts autour des heures de repas. Dans une application unique, la recherche dans les menus, les recommandations, le dispatch et le paiement se disputent les mêmes threads, connexions et mémoire. Une requête lente dans un domaine peut épuiser les ressources dont le paiement a besoin.
Protéger le parcours qui encaisse l'argent
Le premier principe de conception était simple : commande et paiement doivent continuer à fonctionner même si tout le reste est dégradé. Les commandes et les paiements ont donc été séparés en services dédiés, avec leurs propres stockages, et toute autre interaction avec eux a été rendue asynchrone.
Des événements pour tout ce qui peut attendre
Quand une commande est passée, le client a besoin d'une confirmation immédiate. Prévenir le restaurant, affecter un livreur et mettre à jour les statistiques peut se faire un instant plus tard. Un événement « commande passée » publié dans Kafka permet à chaque consommateur de travailler à son rythme – et de tomber en panne sans affecter la commande elle-même.
- Service de commande : accepte la commande et publie un événement.
- Service restaurant : consomme l'événement et met à jour l'écran de cuisine.
- Service de dispatch : consomme l'événement et affecte un livreur.
- Service de notification : informe le client à mesure que les événements de statut arrivent.
Chaque service possède ses données
Les commandes et paiements exigent des transactions et vivent donc dans PostgreSQL. Les menus sont des documents dont la forme varie d'un restaurant à l'autre et vivent dans MongoDB. Les services ne lisent jamais les tables des autres ; ils maintiennent les données dont ils ont besoin à jour grâce aux événements.
Ce que cela coûte
Les systèmes orientés événements sont plus difficiles à comprendre qu'une application unique. Les données sont cohérentes à terme, les pannes peuvent survenir entre les services et déboguer signifie suivre une requête à travers plusieurs processus. Le traçage distribué – ici Zipkin – et des consommateurs idempotents sont l'investissement minimal qui rend cette architecture gérable.
Pour un petit outil interne, ce serait de la sur-ingénierie. Pour une plateforme dont le chiffre d'affaires dépend d'un paiement disponible aux heures de pointe, c'est le bon compromis.
Cet article vous a plu ? Recevez le prochain par e-mail.