Architektura - jaka koncepcja?

Witam,

Proszę Was o różne sugestie, jak rozwiązać problem “powiadamiania” kilku systemów o określonym zdarzeniu.

Sytuacja jest następująca:
System “Z” posiada swoje API (przyjmowanie danych potrzebnych do wystawienia faktury).
W jednej sieci działają cztery inne systemy (powiedzmy “A”, “B”, “C”, “D”), które korzystają z tego API .

System “Z” służy również do gromadzenia informacji o wpłatach.
Próbuję opracować jakieś rozwiązanie, które umożliwi “informowanie” te wszystkie systemy (dzisiaj od A do D, ale w przyszłości może być ich więcej) o zdarzeniu takim jak zarejestrowanie wpłaty.

Pewnie najprościej byłoby dodać API do systemów A…D i wywoływać je w odpowiednim zdarzeniu z systemu Z, ale jak to zrobić inaczej?
Serwer typu push i uruchomienie publishera na systemie Z oraz “nasłuchiwanie” go przez systemy A…D?

Podpowiedzcie proszę, jak poprawnie zaprojektować całość przy założeniu, że liczba systemów, które generują dane do fakturowania i będą musiały odbierać info o wpłatach może się w przyszłości zmieniać (powstaną kolejne “E”, “F”…)

Jak Wy byście to zaprojektowali?

Architektura Producent - Konsument (?)

sorry…nie rozumiem pytania

Sądziłem, że zwrotnie system “Z” winien wysyłać eventy (info o wpłatach) na jakieś Rabbit MQ i tutaj takie zdarzenie na odpowiednią grupę subskrybentów takiej informacji. Dalej, subskrybenci (systemy A…E) konsumują takie powiaadomienie i działają wg własnej logiki.

Ma ktoś może jeszcze jakieś propozycje takiej architektury?