Schema-Versionierung
Einleitung
Schema-Versionierung stellt sicher, dass Änderungen an:
- API-Contracts
- Event-Schemata
- Integrationsformaten
kontrolliert evolvieren können, ohne bestehende Konsumenten zu brechen.
In verteilten Systemen gilt:
Breaking Changes sind Produktionsvorfälle – keine Refactorings.
Einordnung
Schema-Versionierung ist ein Micro-Pattern für Integrationsstabilität.
Es ist zentral in:
- Event-Driven Architectures
- Microservices
- SOA
- CQRS-/Event-Sourcing-Systemen
Es betrifft die Integrationsgrenze, nicht die interne Modellierung.
Grundprinzip
Kernaussage:
- Produzenten entwickeln weiter
- Konsumenten dürfen nicht plötzlich brechen
- Kompatibilität ist explizit geprüft
Zentrale Konzepte
1️⃣ Backward Compatibility
Neue Version kann:
- von alten Konsumenten gelesen werden
Typisch:
- neue optionale Felder
- Default-Werte
- additive Änderungen
2️⃣ Forward Compatibility
Alte Version kann:
- von neuen Konsumenten verarbeitet werden
Wichtig bei:
- Rolling Deployments
- Canary Releases
3️⃣ Deprecation-Zyklen
Statt:
- sofortiger Breaking Changes
Besser:
- markieren
- ankündigen
- Übergangsphase
- entfernen
API-Versionierung
Typische Strategien:
- URL-Versionierung (
/v1/orders) - Header-Versionierung
- Media-Type-Versionierung
Wichtig:
Versionierung ist ein Governance-Thema, kein Routing-Trick.
Event-Schema-Versionierung
Bei Events besonders kritisch:
- Events sind unveränderlich
- Historische Events bleiben bestehen
- Upcaster oder Migrationslogik notwendig
Best Practice:
- Schema Registry (Avro/Protobuf)
- Kompatibilitätsregeln enforced
Datenbank-Migration vs. API-Version
Nicht verwechseln:
- DB-Schema darf sich intern ändern
- Public Contracts müssen stabil bleiben
Interne Migration ≠ Breaking Change für Konsumenten.
Vorteile
- Stabilität in verteilten Systemen
- Ermöglicht Rolling Deployments
- Verhindert Integrationsausfälle
- Kontrollierte Evolution
Risiken / typische Fallstricke
1️⃣ „Wir erhöhen einfach die Version“
Mehr Versionen ohne Deprecation-Strategie:
- erzeugen Wartungslast
- fragmentieren Systeme
2️⃣ Implizite Breaking Changes
Typische Fehler:
- Feld umbenennen
- Typ ändern
- Semantik ändern
Struktur kann gleich bleiben – Bedeutung nicht.
3️⃣ Fehlende Governance
Ohne klare Regeln entstehen:
- Version-Chaos
- Shadow-APIs
- Produktionsfehler
4️⃣ Zu lange Parallel-Versionen
Mehrere aktive Versionen:
- erhöhen Komplexität
- erschweren Testing
Wann besonders wichtig?
- Mehrere externe Konsumenten
- Langlebige Events
- Öffentliche APIs
- Hohe Deployment-Frequenz
Wann weniger kritisch?
- Reiner Monolith
- Interne, kurzlebige Integrationen
- Ein Team, ein Release-Zyklus
Strategische Perspektive
Schema-Versionierung ist:
- ein Stabilitätsinstrument
- ein Governance-Mechanismus
- eine Voraussetzung für autonome Teams
Ohne Versionierungsstrategie entsteht:
enge Release-Kopplung oder Integrationsinstabilität.
Fazit
Schema-Versionierung ermöglicht kontrollierte Evolution.
Sie verlangt:
- Disziplin
- klare Kompatibilitätsregeln
- Deprecation-Strategie
- technische Durchsetzung (z. B. Registry)
In verteilten Architekturen ist sie keine Option – sondern Pflicht.