Technical Tutorials

Dans le domaine des applications monolithiques, la cohérence des données est simple à maintenir. Une seule transaction de base de données garantit que toutes les étapes d'un processus métier réussissent ou échouent ensemble. Cependant, à mesure que nous migrons vers une architecture de microservices, cette simplicité disparaît. Chaque service possède sa propre base de données, rendant les transactions ACID traditionnelles impossibles entre les services. C'est ici que le Pattern Saga devient un outil essentiel pour l'architecte logiciel moderne.

Le Problème : Cohérence des Données Distribuées

Lorsqu'un processus métier s'étend sur plusieurs services, comme un flux de commande e-commerce impliquant un Service d'Inventaire, un Service de Paiement et un Service de Livraison, nous sommes confrontés au défi des transactions distribuées. Nous ne pouvons pas utiliser le protocole standard de commit en deux phases (2PC) dans de nombreux environnements modernes en raison de sa latence élevée, de son couplage serré et de son potentiel de points de défaillance uniques. Au lieu de cela, nous avons besoin d'un pattern qui permet aux transactions de longue durée de maintenir la cohérence grâce à une séquence de transactions locales, chacune ayant une action compensatoire correspondante.

Fonctionnement du Pattern Saga

Un Saga est une séquence de transactions locales. Chaque transaction locale met à jour la base de données et publie un événement ou un message pour déclencher la transaction locale suivante dans le saga. Si une étape échoue, le saga exécute une série de transactions compensatoires pour annuler les modifications apportées par les étapes précédentes. Il existe deux façons principales d'implémenter les sagas :

Chorégraphie : Les services communiquent via des événements sans coordinateur central.
Orchestration : Un coordinateur central dirige le flux du saga.

Chorégraphie vs Orchestration

Bien que la chorégraphie soit plus simple pour les petits systèmes, elle peut devenir difficile à tracer et à déboguer à mesure que la complexité augmente. L'orchestration, en utilisant un coordinateur comme AWS Step Functions ou Temporal, offre une meilleure visibilité et un meilleur contrôle, mais introduit un nouveau point de défaillance si elle n'est pas conçue avec soin.

Exemple de Code Pratique : Approche par Chorégraphie

Examinons un exemple simplifié en Node.js d'un saga basé sur la chorégraphie pour un processus de "Passation de Commande". Ici, nous supposons l'utilisation d'un bus d'événements comme RabbitMQ ou Kafka.

// Étape 1 : Créer la commande (Transaction locale)
async function handleOrderCreated(event) {
    try {
        // Réserver l'inventaire localement
        await inventoryService.reserve(itemIds, quantity);
        
        // Publier l'événement pour déclencher le paiement
        eventBus.publish('ItemsReservedEvent', { orderId: event.orderId });
    } catch (error) {
        // Compensation : Si la réservation échoue, notifier l'annulation de la commande
        eventBus.publish('OrderFailedEvent', { orderId: event.orderId });
    }
}

// Étape 2 : Traiter le paiement (Déclenché par ItemsReservedEvent)
async function handleItemsReserved(event) {
    try {
        await paymentService.charge(event.orderId, amount);
        
        // Succès : Passer à la livraison
        eventBus.publish('PaymentCompletedEvent', { orderId: event.orderId });
    } catch (error) {
        // Compensation : Annuler la commande (ce qui déclenchera la libération de l'inventaire)
        eventBus.publish('OrderFailedEvent', { orderId: event.orderId });
    }
}

// Étape 3 : Annuler la commande (Action compensatoire)
async function handleOrderFailed(event) {
    // Libérer l'inventaire
    await inventoryService.release(event.orderId);
    // Rembourser le paiement s'il a déjà été débité
    await paymentService.refund(event.orderId);
}

Défis Clés et Considérations

La mise en œuvre des sagas n'est pas sans écueils. Les développeurs doivent gérer soigneusement l'idempotence, car les nouvelles tentatives de réseau peuvent entraîner l'exécution multiple de la même étape. De plus, l'observabilité est critique ; sans traçage distribué, le débogage d'un saga échoué sur cinq services peut être un cauchemar. Enfin, prenez en compte les temporisations (timeouts) ; si un service devient non réactif, le saga doit être capable de le détecter et d'initier une compensation plutôt que de rester bloqué indéfiniment.

Conclusion

Le Pattern Saga est une solution robuste pour gérer les transactions distribuées dans les architectures de microservices. En remplaçant les transactions ACID rigides par des workflows flexibles et compensatoires, il permet aux systèmes de rester faiblement couplés tout en préservant la cohérence des données. Que vous choisissiez la chorégraphie pour sa simplicité ou l'orchestration pour son contrôle, comprendre le Pattern Saga est obligatoire pour tout développeur construisant des systèmes distribués évolutifs et résilients.