Architektur: Disconnected Services mit Message-Queue

Hi...

ich spiel mich grade mit (Micro)services und Message-Queues (im speziellen Azure Service Bus) und hätte eine Architekturfrage weil ich mir nicht ganz sicher bin was die "sauberste" Lösung ist.

Beispiel:

Ticket-Service (zuständig für CRUD-Operationen bei Tickets)
Notification-Service (zuständig für Senden von Email-Benachrichtigungen)

Über Ticket-Service wird nun eine neues Ticket erstellt und einem Benutzer zugewiesen. Das Ticket-Service sendet eine "neues-Ticket"-Message in den Notification-Queue.

Notification-Service empfängt die Message und soll an den Benutzer eine Email senden.

Nun gibt es meiner Meinung nach 2 Möglichkeiten:

• Alle für das Senden der Nachricht notwendigen Daten (Benutzer und Ticket-Infos) werden direkt in der Message übergeben.

• In der Message wird nur die Ticket-Id übergeben und das Notification-Service holt sich die notwendigen Daten vor dem Senden über z.B. eine Web-API die das Ticket-Service zur Verfügung stellt.

Welche Variante wäre die bessere?

lg

Hallo,

pauschal lässt sich das nicht sagen, obwohl ich zu Variante 1 tendiere.
Ein Faktor könnte z.B. die maximale Größe einer Nachricht der Messagequeue sein. Falls deine Payload größer als ein paar KB sein sollte, gibt es möglicherweise Einschränkungen seitens Azure Service Bus.
Variante 2 könnte problematisch sein falls du replizierte und nicht (bzw. letztendlich) konsistente Datenspeicher verwendest. Wenn beim Einfügen deiner Nachricht in die Queue beispielsweise noch nicht alle Replikate aktualisiert wurden und sich deine Queue die Daten aus einem nicht aktualisierten Replikat holt, dann wäre das ein Problem.
Zudem vermeidet Variante 1 eine Abhängigkeit zum Ticket-Service.

Das kommt jetzt ziemlich drauf an, was das für ein Notificationsystem sein soll.

Gründe, die dies beeinflussen:

• Wenn der Benutzer aktuell aktiv in der Anwendung ist, dann reicht evtl. nur eine Nachricht via WebSocket, die im Browser aufpoppt. Kein Grund ihm da eine (zusätzliche) E-Mail zu senden.
• Wenn er nicht in Aktiv in der Anwendung ist, oder die Websocket-Nachricht nicht nach x Minuten liest, dann greift eine Eskalationsstufe, die ihm dann doch die E-Mail senden
• Ist der Benutzer überhaupt nicht aktiv, ist es nacht oder hat die Notification eine gewisse Priorität, dann kannst Du das entsprechend nach Eskalationsstufe erweitern und dann zusätzlich oder direkt eine SMS oder einen automatischen Anruf absetzen.

Notifications sind übrigens nen schlechtes Beispiel für Microservices; denn Notifications sind ein Service-übergreifendes Element, für das man dann doch i.d.R. wieder auf einen Enterprise-Bus zurück greift.
Enterprisebus Elemente können generische Informationen kennen; müssen sie aber nicht.

Dahingehend tendiere ich bei diesen beiden Auswahlmöglichkeiten auch zu 1.
Sollte das Ticket aber ein zentraler Bestandteil des Enterprise-Elements / des Kernbusiness sein, dann könnte es auch Variante 2 sein.