Viele Organisationen nutzen Microservices, doch der Einsatz erschwert die synchronisierte Kommunikation zunehmend. Dass alle Systeme jederzeit verfügbar und alle Änderungen zu jedem Zeitpunkt konsistent sind, lässt sich nicht mehr sicherstellen. Und die enge Verknüpfung der Dienste durch die synchrone Kommunikation kann dazu führen, dass der Ausfall eines Dienstes gleichzeitig den Ausfall einer Reihe weiterer Dienste zur Folge hat. Typische Resilience Patterns wie Circuit-Breaker, Retries und Service Meshes erhöhen wiederum die Komplexität des Gesamtsystems und lösen das eigentliche Problem nur teilweise.

In diesem Artikel möchte ich verschiedene Arten der Architektur und asynchronen Kommunikation erläutern, und dabei die Vor- und Nachteile sowie die Herausforderungen jeder Art diskutieren.

Request-Driven Architektur

Die klassische Microservice-Architektur, oft auch als Request-Driven- oder Request/Response-Modell bezeichnet, basiert auf direkten Anfragen zwischen Services, meist über RESTful APIs. In diesem Modell sendet ein Dienst eine Anfrage an einen anderen und wartet auf die Antwort, bevor er fortfahren kann. Diese Methode ist leicht verständlich, da sie einem einfachen Frage-Antwort-Schema folgt, das dem menschlichen Dialog ähnelt: Ein Dienst fragt nach Informationen oder bittet um eine Handlung, ein anderer antwortet.