La raison principale d'adopter une architecture orientée événements n'est pas que cela sonne moderne. C'est que cela permet aux systèmes de réagir au même changement sans être étroitement couplés au même chemin de requête.
Cela est utile lorsque :
- plusieurs services se préoccupent du même événement de domaine
- les réactions en quasi temps réel sont importantes
- les consommateurs doivent évoluer indépendamment
Kafka est une manière d'y parvenir car il vous fournit un journal durable d'événements plutôt qu'un appel point à point.
Ce qui change
Au lieu qu'un service appelle directement chaque système dépendant, il publie un événement et passe à autre chose. Les systèmes en aval décident comment le consommer.
Un contrat d'événement simple pourrait ressembler à ceci :
{
"type": "order.created",
"orderId": "ord_123",
"customerId": "cus_456",
"occurredAt": "2024-07-20T10:00:00Z"
}
Cela vous procure un découplage. Cela entraîne également plus de complexité opérationnelle :
- questions de commande
- idempotence
- comportement de rejouement
- latence et santé des consommateurs
Ainsi, le véritable argument en faveur de Kafka n'est pas que "le temps réel est meilleur que les tâches cron" comme slogan. C'est que certains domaines bénéficient de l'expression des changements commerciaux sous forme de flux d'événements plutôt que d'un ensemble d'appels synchrones étroitement liés.
Quand cela en vaut la peine
Utilisez une architecture orientée événements lorsque plusieurs réactions indépendantes sont importantes.
N'utilisez pas Kafka simplement pour éviter d'écrire un code d'application simple pour un système CRUD basique.
Lectures complémentaires