API-Design und Datenarchitektur bestimmen, wie sich das System unter Last verhält und skaliert. Fehler sind hier selten sofort sichtbar, kosten aber später viel.
Das Problem zeigt sich nicht beim Start, sondern beim Wachstum des Systems. Solange die Last niedrig und das Team klein ist, erscheinen sowohl die API als auch die Datenschicht „ausreichend gut“. Mit der Zunahme der Kunden, Datenquellen und Integrationen beginnt das System jedoch, an Vorhersehbarkeit zu verlieren. In der API äußert sich dies in instabilen Verträgen, nicht offensichtlichen Fehlern und Kompatibilitätsproblemen. In der Datenarchitektur zeigt es sich in Daten-Duplikaten, widersprüchlichen Definitionen und dem Verlust des Vertrauens in Metriken. Der kritische Punkt tritt ein, wenn verschiedene Teams dieselben Entitäten unterschiedlich verstehen.
Die Lösungen sind hier nicht universell, und das ist der entscheidende Punkt. In der Datenarchitektur ist die Wahl zwischen Data Warehouse, Data Lake und Data Mesh keine Frage des „besten Ansatzes“, sondern von Kompromissen. Das Warehouse bietet ein strenges Schema und schnelle Abfragen, passt sich jedoch schlecht an neue Quellen an. Der Lake bietet Flexibilität und Skalierung, verwandelt sich jedoch ohne strenge Regeln schnell in ein unkontrollierbares Lager. Data Mesh verteilt das Datenbesitz über die Teams, was Engpässe verringert, aber reife Prozesse und Verantwortung vor Ort erfordert. Ähnlich verhält es sich bei der API: REST, GraphQL, gRPC oder Webhooks sind Entscheidungen für ein bestimmtes Szenario und kein Standard.
Die praktische Umsetzung scheitert an den Details. Im API-Design sind es gerade die „Kleinigkeiten“, die die Hauptlast auf das System legen:
- HTTP-Methoden und Statuscodes bestimmen die Vorhersehbarkeit des Verhaltens
- Die Struktur von Anfragen und Antworten beeinflusst die Kompatibilität
- Versionierung und Paginierung bestimmen die Langlebigkeit der API
Eine separate Schicht ist die Zuverlässigkeit. Ohne durchdachte Mechanismen wie Retries, Timeouts, Idempotenz und Rate Limiting beginnt das System unter Last zu degradieren. Diese Elemente werden oft später hinzugefügt, wenn Vorfälle auftreten, obwohl sie von Anfang an die Widerstandsfähigkeit formen.
In der Datenarchitektur ist die Situation ähnlich. Der Data Lake bietet Freiheit, aber ohne Regeln für Benennungen, Formate und Besitz entstehen schnell:
- Daten-Duplikate
- Unterschiedliche Definitionen derselben Metriken
- Veraltete oder ungenutzte Datensätze
Data Mesh versucht, dies durch verteilte Verantwortung zu lösen. In der Praxis verschiebt sich das Problem jedoch von der Technologie zur Organisation. Jedes Team muss in der Lage sein, die Datenqualität, Dokumentation und den Zugang zu verwalten. Wenn dies nicht der Fall ist, wird das System noch fragmentierter.
Ein separater Aspekt sind die Methoden zur Bereitstellung von Daten und Ereignissen. Hier sind die Kompromisse zwischen Einfachheit und Effizienz besonders deutlich:
- Polling ist einfach zu implementieren, erzeugt jedoch zusätzliche Last
- Long Polling reduziert die Anzahl leerer Antworten, hält jedoch die Verbindungen offen
- SSE bietet Streaming über eine Verbindung, jedoch nur in eine Richtung
- Webhooks beseitigen vollständig die Notwendigkeit des Pollings, erfordern jedoch eine zuverlässige Verarbeitung eingehender Ereignisse
In der Praxis verwenden Systeme selten einen einzigen Ansatz. Eine Kombination von Mustern ermöglicht es, Latenz und Durchsatz je nach Szenario auszubalancieren.
Die Ergebnisse solcher Lösungen sind schwer sofort zu messen. Es gibt keine einzige Metrik, die „eine gute API“ oder „eine richtige Datenarchitektur“ zeigt. Aber es gibt indirekte Signale:
- Teams streiten weniger über die Werte von Metriken
- APIs werden ohne ständige Klarstellungen verwendet
- Vorfälle sind mit der Geschäftslogik und nicht mit der Infrastruktur verbunden
- Änderungen brechen keine bestehenden Kunden
Wenn diese Signale fehlen, liegt das Problem fast immer nicht in der Technologie. Es liegt in der Inkonsistenz der Entscheidungen: Verschiedene Teams interpretieren Verträge, Daten und Verantwortlichkeiten unterschiedlich.
Die Verbindung von API-Design + Datenarchitektur ist kein zwei separaten Schichten. Es ist ein einheitliches System von Verträgen. Die API definiert, wie Daten übertragen werden. Die Datenschicht definiert, wie sie interpretiert werden. Wenn diese beiden Ebenen auseinanderdriften, verliert das System seine Integrität.
Genau deshalb verlieren architektonische Entscheidungen hier selten aufgrund von Technologien. Sie verlieren aufgrund mangelnder Konsistenz zwischen den Teams.