Wie verhinderst du, dass eine Backend-Änderung die Clients bricht, die deine API nutzen?

Mach den Vertrag maschinell prüfbar. Halt ein Schema vor, ein OpenAPI-Dokument oder protobuf-Definitionen, generiert aus dem Code oder gegen ihn validiert, und fahr in der CI eine Kompatibilitätsprüfung, die bei einer Breaking Change wie einem entfernten Feld oder einem verschärften Typ fehlschlägt. Ergänz Consumer Driven Contract Tests für interne Clients, und versionier Events genauso wie Endpoints.

Der Vertrag muss eine Datei sein, die die CI vergleichen kann, sonst hängt Kompatibilität an dem, der den Pull Request reviewt. Das OpenAPI-Dokument liegt also im Repository und wird aus den Handlern generiert, damit es nicht in die Fiktion abdriftet, und es gibt einen Job, der es gegen die Version auf dem Main-Branch diffed und bei allem Brechenden fehlschlägt: ein entferntes Feld, ein neuer Pflichtparameter, ein verengter Typ. Hinzufügen ist immer erlaubt. Für interne Konsumenten mag ich Consumer Driven Contracts, bei denen jeder Client die Teilmenge veröffentlicht, auf die er sich wirklich verlässt, und mein Build verifiziert, dass ich sie alle noch erfülle, ich erfahre es also zur Buildzeit und nicht von deren Bereitschaft. Events bekommen dieselbe Behandlung über eine Schema Registry mit gesetztem Kompatibilitätsmodus, denn ein kaputtes Event-Payload ist schlimmer als ein kaputter Endpoint, weil Konsumenten asynchron scheitern. Und bevor ich etwas ändere, schaue ich in die Request-Metriken pro Client, denn der Vertrag sagt mir, was möglich ist, und die Metriken sagen mir, wer es tatsächlich merken würde.