Wie baut man komplexe JOIN-Abfragen in einer Microservice-Architektur?

Hi...

Ich beschäftige mich gerade ein bisschen mit Microservices.

Wen man die Services komplett entkoppelt, dann gibt es für jedes Service eine eigene Datenbank (eventuell sogar eigene Server).

Nehmen wir mal an es gibt Services für:

CustomerManagement
OrderManagement
ProductManagement

Normale einfache CRUD-Operationen sind kein Problem.
Wo ich gerade häng sind komplexere Abfragen. In den Beispielen im Web wird sowas leider nicht behandelt.

Vom Datenbank-Schema her wäre das dann ungefähr so:

Customer hat Orders
Order hat OrderItems
OrderItem hat Product

Wie behandle ich in entkoppelten Microservices nun Abragen die "JOINS" über mehrer Tabellen benötigen würden.

z.B.
alle Kunden die in den letzten 4 Wochen Artikel der Marke "XY" gekauft haben

Wie löst man sowas wenn man die Tabellen eben nicht in einer Datenbank haben möchte.

lg
M@TUK

Einen pauschalen Weg gibt es hier nicht.
Aber im Prinzip ist es legal, dass ein OrderService einen CustomerService für gewisse Dinge aufrufen darf.
Das ist dann quasi ein Thema der Microservice Orchestration bzw. Choreography.

Gut erklärt ist es hier:
https://specify.io/concepts/microservices#choreography

In den meisten Fällen ist eine Orchestration weniger komplex als eine Choreography.
Die Choreography lohnt sich erst bei sehr viel größeren Anwendungen.

Aber die Frage

alle Kunden die in den letzten 4 Wochen Artikel der Marke "XY" gekauft haben

Wie löst man sowas wenn man die Tabellen eben nicht in einer Datenbank haben möchte.

kann damit beantwortet werden, dass dies nur den OrderService betrifft.
Denn bei Bestellungen muss es Datenredundanzen geben.

Eine Bestellung darf nicht geändert werden, niemals.
Wenn sich ein Artikel ändert oder eine Kundenadresse, muss die Bestellung immer noch gleich bleiben.

Ansonsten gibt es i.d.R eine Suche-Engine über alle Microservices, über die ein Join potentiell laufen kann.
Je nachdem wie schnell das sein muss kann das zB. eine Azure Search Engine sein oder zB. in einem Data Lake.

Hi,

Vielen Dank...

Das würde dann bedeuten, dass man (ohne Search oder Data Lake) alle für eine Abfrage notwendigen Werte redundant speichern und gegebenenfalls über Messaging/Events synchronisieren muss um eine performante Abfrage zu ermöglichen.

Schön langsam wird ein Schuh draus... 😃

lg

Nein, das kommt ganz einfach drauf an.

Es gibt Business Logik, da musst Du Redunanzen führen. Dazu gehören Bestellungen und Rechnungen.
Die Redundanzen haben aber nichts mit der Architektur zutun.

Aber nein, Du musst nicht alle Daten redundant speichern oder synchronisieren.
Ein Weg wäre, dass Service A einfach Service B aufruft.