Praxis: Bestellsystem mit Microservices

Service-Schnitt

• OrderService — Bestell-Verwaltung
• InventoryService — Bestände, Reservierungen
• PaymentService — Zahlungen via Stripe
• EmailService — Transaktional + Marketing
• AnalyticsService — Tracking, Reporting

Bestell-Flow als Saga

1. Order erstellen → Status: pending
2. Event "OrderPlaced" publizieren
3. InventoryService reserviert → Event "InventoryReserved"
4. PaymentService chargt → Event "PaymentSucceeded" oder "PaymentFailed"
5. Bei Erfolg: Order → confirmed, EmailService sendet Bestätigung
6. Bei Fehler: Compensating "ReleaseInventory", Order → cancelled, Email "Zahlung fehlgeschlagen"

Was schiefgehen kann

• Inventory reserviert, Payment hängt → Saga-Timeout, Inventory-Release nach 15 min
• Email-Service down → Event in Queue, später nachholen
• Doppelte Charge bei Retry → Stripe-Idempotency-Key nutzen
• Analytics down → Events queuen, später nachverarbeiten (kein Bestell-Block)

Tech-Stack

Broker:       Kafka (3 Brokers, Replikation 3)
Services:     Node.js / Go (je nach Team)
DB pro Svc:   PostgreSQL (Outbox-Pattern)
Tracing:      OpenTelemetry → Tempo
Metrics:      Prometheus → Grafana
Logs:         JSON → Loki
Orchestrator: Kubernetes
API-Gateway:  Kong oder Envoy

Faustregeln

• Maximal 5-10 Services im ersten Schnitt — sonst zu viel Coordination-Overhead
• Jeder Service hat 1 Owner-Team
• API-Versions-Management von Tag 1
• Schema-Registry für Event-Payloads (Avro / Protobuf)