HTTP-Feeds: Asynchrone Schnittstellen ohne Kafka oder RabbitMQ

Seite 3: Housekeeping und DSGVO-Anforderungen

Inhaltsverzeichnis

Feeds enthalten in der Regel historische Daten. Das wirft wichtige Fragen auf: Wie lange sind die Daten vorzuhalten, und wie sind sie zu entfernen, wenn beispielsweise eine Nutzerin oder ein Nutzer sein Recht auf Löschung gemäß der DSGVO geltend macht?

Die minimale Vorhaltedauer fachlicher Events ist zunächst eine fachliche Entscheidung. Grundsätzlich ist es aber ratsam, den Feed kompakt zu halten, damit neue Consumer ihn auch zügig von Anfang bis Ende lesen können. Bei Event-Feeds ist beispielsweise eine Vorhaltedauer von vier Wochen denkbar und sinnvoll; ältere Einträge werden gelöscht.

Bei Data-Feeds, die alle Entitäten enthalten müssen, empfiehlt sich die Verwendung eines fachlichen Schlüssels, der die fachliche Entität referenziert. Das kann beispielsweise eine Kundennummer, eine Bestellnummer oder auch eine entsprechende URI sein. Beim Implementieren des Feeds lassen sich dann alle bisherigen Einträge mit dem gleichen fachlichen Schlüssel entfernen, sobald ein neuer Eintrag mit dem vollständigen aktuellen Zustand dieser Entität hinzukommt. Auf diese Weise sind im Feed langfristig alle Entitäten nur einmal enthalten, und zwar immer auf dem neuesten Stand. Dieser Vorgang nennt sich Compaction.

Durch einen Compaction-Lauf lassen sich ältere Einträge mit dem gleichen fachlichen Schlüssel aus dem Feed entfernen (Abb. 7).

Der fachliche Schlüssel kann auch für DELETE-Events zum Einsatz kommen. Dazu fügt man einen leeren Feed-Eintrag mit dem gleichen fachlichen Schlüssel und einer DELETE-Kennzeichnung hinzu. Nach einem Compaction-Lauf sind dann alle vorherigen Einträge entfernt. Consumer des Feeds können auf diese DELETE-Events ebenfalls mit einer Löschaktion in ihren Datenbeständen reagieren.

Als Alternative zu Message-Broker-Systemen eignen sich HTTP-Feeds für den Aufbau asynchroner, Event-getriebener Architekturen und Integrationsmuster, da sie sowohl die Datenreplikation zwischen Systemen als auch nachgelagertes Auslösen von Aktionen durch die Verarbeitung von Domain-Events ermöglichen. Vor allem, wenn team- oder systemübergreifende Schnittstellen notwendig sind, haben reine HTTP-Schnittstellen genauso wie REST-APIs den Vorteil, dass sie ohne ein Middleware-System auskommen und dadurch auch organisatorische und technologische Abhängigkeiten entfallen.

Jochen Christ
ist Senior Consultant bei INNOQ. Er ist Spezialist für Softwarearchitekturen mit Fokus auf Self-contained Systems, modernen Java-Technologien und Cloud Computing. Als Technical Leader unterstützt er Teams bei der Umsetzung komplexer Transformationen. Er ist zudem Maintainer von rest-feeds.org und Co-Autor von remotemobprogramming.org.

(map)