Sehr grob und unübersichtlich, aber ich hoffe man versteht es:
Jeder Service bekommt über Events (/Messages) das, was für ihn interessant ist, und speichert das alles lokal bei sich ab.
Der User-Service veröffentlicht alle Änderungen an Kunden-Daten, zB Login-Daten oder Preis-Berechnung. Hersteller und Master-Service subscriben sich an der Topic dafür.
Der Hersteller-Service interessiert sich zb für die Login-Daten eines Kunden für den Hersteller, wenn er das Event bekommt, und speichert alles was er baucht lokal bei sich ab.
Der Master-Service macht das gleiche für die Daten die ihn interessieren, zB die Preisberechnung.
Brauchen Master-/Hersteller-Service dann welche von den Daten, haben sie die lokal direkt verfügbar.
Der Scheduler informiert die Hersteller Services, dass sie arbeiten sollen.
Das könnten die Services auch einfach selbst machen, damit sind die tendenziell auch freier in der Entscheidung und können das zB von lokaler Last abhängig machen.
Dabei gibts paar Einschränkungen zb Wartungsmodus, dann darf kein Hersteller beginnen.
Ist der Wartungsmodus Teil der Business-Logik, also in der Fachlichkeit vorhanden, sowas wie "Hersteller X macht Urlaub, in der Zeit darf man keine Anfragen stellen"?
Oder eher auf Infrastruktur/Anwedungsseite, sowas wie "Hardware wird getauscht"?
Ersteres kann man auch einfach über Events löse, Service bekommt das Event über Start/Ende des "Wartungsmodus" und reagiert entsprechend.
Letzeres würd ich unabhängig davon lösen, und von der Business-Logik trennen.
Zudem prüft er ob die Einstellungen valide sind, wenn nicht bekommt der User eine Info dass das Update aufgrund XXX nicht starten konnte.
Warum muss das stündlich geprüft werden? Kann es passieren, das valide Daten plötzlich, ohne äußeres Ereignis, invalide werden?
Wenn Nein -> dann brauchts keine stündliche Prüfung, Invalide Daten sollten den Hersteller-Service auch gar nicht erreichen.
Wenn Ja -> Event für "Daten wieder gültig"/"Daten nicht gültig".