Microservices

Dieser Beitrag ist eine Begriffserklärung zur Microservices-Architektur – inklusive Prüfungsfragen, Kernkomponenten und Tags.

In a Nutshell

Microservices sind kleine, eigenständig deploybare Dienste mit klar abgegrenzter Fachverantwortung. Jeder Service kapselt Daten und kommuniziert über wohldefinierte Schnittstellen.

Kompakte Fachbeschreibung

Ein System wird in fachlich geschnittene Dienste aufgeteilt – oft entlang eines Bounded Context (DDD). Jeder Dienst besitzt eigenes Datenmodell und eigene Persistenz.

Kommunikation:

• bevorzugt asynchron über Events
• synchron sparsam über REST/gRPC

Konsistenz ist meist eventual. Verteilte Transaktionen werden über Sagas koordiniert. Zuverlässige Nebenwirkungen werden über Outbox/Inbox und idempotente Handler abgesichert.

Betrieblich sind CI/CD, Container-Orchestrierung (z.B. Kubernetes), Observability (Logs/Metriken/Traces) und Security by Default (Zero Trust, mTLS, OAuth/OIDC, Secrets) essenziell.

Anti-Pattern: Verteilter Monolith (zu starke synchrone Ketten oder gemeinsame DB).

Prüfungsrelevante Stichpunkte

• Fachlicher Schnitt: Bounded Context; Daten pro Service; kein Shared Schema
• Asynchron bevorzugt, synchron sparsam (Latenz/Kaskadenfehler)
• Sagas, Outbox/Inbox, Idempotenz
• IHK: Qualitätsziele/SLOs benennen
• Security: mTLS, OAuth/OIDC, Secrets, Rate Limiting
• Wirtschaftlichkeit: Autonomie vs. höherer Betriebsaufwand
• Doku: C4 (L1-L3), ADRs, Schnittstellenverträge, Betriebskonzept

Kernkomponenten

1. Bounded Context
2. API-Design + Versionierung
3. Daten pro Service
4. Messaging/Queues/Streams
5. Service Discovery/Gateway
6. Resilienz (Timeouts, Retries, Circuit Breaker)
7. Observability + Correlation IDs
8. CI/CD + IaC
9. Security (AuthN/AuthZ, Secrets)
10. Tests (Contract/Chaos/Last)

Praxisbeispiel (Saga)

Order Service erstellt Order (pending) + Event (Outbox)
Orchestrator:
- ruft Payment Service (Idempotency Key)
- ruft Inventory Service (Reservation)
- bestätigt Order oder kompensiert (Refund/Cancel)

Praxisbeispiel (Online-Shop als Microservices)

Nutzerverwaltung (z.B. Java + PostgreSQL)
Produktkatalog (z.B. Node.js + MongoDB)
Bestellabwicklung (z.B. Python + Message Broker)
Kommunikation: REST + Events

Erklärung: Jeder Service hat eine eigene Datenbasis, kann unabhängig skaliert und gewartet werden. Änderungen in einem Service sollen die anderen nicht direkt brechen (saubere Verträge/Versionierung).

Vorteile und Nachteile

Vorteile

• Unabhängige Deployments
• Skalierung pro Service
• Bessere Fehlereingrenzung
• Teamautonomie

Nachteile

• Höhere Betriebs-/Architekturkomplexität
• Verteilte Fehlersuche schwieriger
• Datenkonsistenz muss explizit modelliert werden

Typische Prüfungsfragen (mit Kurzantwort)

1. Wie schneidet man Microservices fachlich? Entlang Bounded Context (DDD).
2. Wie koordiniert man verteilte Transaktionen? Saga + Kompensation + Outbox.
3. Warum sind synchrone Ketten problematisch? Latenz und Kaskadenausfälle.
4. Was bedeutet „Daten pro Service“? Jede DB gehört einem Service; Zugriff nur über APIs/Events.

Freie Antwort

Microservices lohnen sich nur, wenn Domänenschnitt, Plattform/DevOps und Observability/Security vorhanden sind. Sonst entsteht schnell ein verteilter Monolith.

Lernstrategie

1. 3-Services-Architektur analysieren (APIs/Events/Datenhoheit).
2. Saga-Sequenzdiagramm inkl. Fehlerpfade erstellen.
3. Vor-/Nachteile tabellarisch üben.
4. Gemeinsame DBs vermeiden.

Typisches Tooling (Praxis)

• Docker / Kubernetes
• OpenAPI/Swagger für API-Dokumentation
• Metriken/Monitoring (z.B. Prometheus, Grafana)
• Tracing (z.B. Zipkin/Jaeger)

Wichtigste Quellen

1. https://microservices.io
2. https://martinfowler.com/microservices