An Business Capabilities schneiden
Grenzen entlang fachlicher Domänen und klarer Verantwortlichkeiten ziehen. Technische Schichten wie API, Worker und Datenzugriff gehören meistens in denselben Service, wenn sie dieselbe Fähigkeit bedienen.
CH/DE Leitfaden
Microservices, die fachlich klar, lose gekoppelt und betreibbar bleiben.
Diese Seite fasst bewährte Richtlinien für Microservices und Event Driven Architecture zusammen: von Service-Grenzen über Event-Contracts bis zu Observability, Deployment und Teamverantwortung.
Grundlagen
Service-Grenzen
Ein Microservice ist nicht einfach ein kleiner Deployable. Er kapselt eine fachliche Fähigkeit, Datenhoheit und operative Verantwortung.
Datenhoheit respektieren
Jeder Service besitzt seine Daten. Andere Services lesen nicht direkt in fremden Datenbanken, sondern nutzen APIs, Events oder replizierte Read Models.
Kopplung aktiv reduzieren
Synchrone Aufrufe sparsam einsetzen, Timeouts und Fallbacks definieren und keine internen Modelle als öffentliche Verträge veröffentlichen.
Autonome Lieferfähigkeit sichern
Ein Service sollte unabhängig getestet, deployed, skaliert und zurückgerollt werden können. Gemeinsame Bibliotheken klein halten und nicht zur versteckten Plattform machen.
Event Driven Architecture
Ereignisse als fachliche Fakten
Events entkoppeln Abläufe, erhöhen aber die Anforderungen an Verträge, Idempotenz, Reihenfolge und Fehlerbehandlung.
Events in Vergangenheitsform benennen
Ein Event beschreibt, was fachlich passiert ist: OrderPlaced, PaymentCaptured oder ContractCancelled. Es ist kein versteckter Remote Procedure Call.
Verträge versionieren
Schemas sind produktionsrelevante Schnittstellen. Änderungen müssen abwärtskompatibel geplant, dokumentiert und mit Consumer-Tests abgesichert werden.
Idempotenz einbauen
Consumer müssen doppelte Zustellungen aushalten. Event-ID, Aggregate-ID, dedizierte Inbox/Outbox und nachvollziehbare Retry-Strategien sind zentrale Bausteine.
Konsistenz bewusst gestalten
Eventual Consistency ist ein Designentscheid. Benutzeroberflächen, SLAs und Support-Prozesse müssen Verzögerungen und Zwischenzustände verständlich abbilden.
Betrieb
Produktionsreife von Anfang an
Verteilte Systeme brauchen Disziplin im Betrieb. Ohne Observability, klare Ownership und Resilienz werden kleine Services schnell zu grossen Abhängigkeiten.
Observability standardisieren
Metriken, Logs und Traces mit Correlation IDs durch alle Services und Events führen. Dashboards sollten fachliche und technische Signale kombinieren.
Fehler isolieren
Timeouts, Circuit Breaker, Bulkheads und Dead-Letter Queues verhindern Kaskadenfehler. Retries brauchen Limits, Backoff und klare Alarmierung.
Deployment klein halten
Automatisierte Tests, Contract Checks, Datenbankmigrationen und progressive Releases reduzieren Risiko. Rollbacks dürfen kein Ausnahmeprozess sein.
Ownership sichtbar machen
Für jeden Service braucht es ein Team, eine Kontaktstelle, Runbooks, Service Level Objectives und klare Regeln für Breaking Changes.
Praktisch
Checklisten vor dem Go-live
Diese Fragen helfen, Architekturentscheidungen greifbar zu machen und Risiken früh sichtbar zu halten.
Service Design
- Ist die fachliche Verantwortung in einem Satz erklärbar?
- Besitzt der Service seine Daten und Migrationsstrategie?
- Sind öffentliche APIs und Events dokumentiert und versioniert?
- Kann das Team unabhängig releasen und zurückrollen?
Event Flow
- Sind Producer, Consumer und erwartete Latenzen bekannt?
- Sind Event-Schemas kompatibel und getestet?
- Sind Consumer idempotent und retry-fähig?
- Gibt es Monitoring für Lag, Fehler und Dead Letters?
Betrieb
- Sind SLOs, Alerts und Runbooks vorhanden?
- Gibt es Tracing über synchrone und asynchrone Grenzen?
- Sind Secrets, Zugriffe und Datenklassifizierung geprüft?
- Sind Kapazität, Kosten und Skalierungsgrenzen verstanden?