Im Deutschen hat sich eine Übersetzung eingebürgert, die das Denken über verteilte Systeme in eine falsche Richtung lenkt. „Eventual Consistency“ wird häufig als „eventuell konsistent“ wiedergegeben. Eventuell, also möglicherweise. Eine Datenbank, die möglicherweise konsistent ist, klingt nach einem System, dem man besser nicht vertraut. Kein Wunder, dass viele Entwicklerinnen und Entwickler reflexartig nach stärkeren Garantien greifen, sobald der Begriff fällt.

Die englische Bedeutung von „eventual“ ist jedoch eine andere. Sie meint „letztendlich“ oder „am Ende“. Eventual Consistency bedeutet also nicht, dass Konsistenz vielleicht eintritt. Sie bedeutet, dass Konsistenz verlässlich eintritt, nur nicht sofort. Die Frage ist nicht, ob, sondern wann. Und diese Frage ist keine technische, sondern eine fachliche. Das war sie schon immer.

Ein besseres mentales Modell als „möglicherweise inkonsistent“ ist das der veralteten Daten. In jedem Moment kann irgendein Teil eines Systems auf Daten zugreifen, die den allerletzten Stand nicht widerspiegeln. Die Daten sind nicht falsch. Sie sind nur nicht aktuell. Sie waren vor einem Moment korrekt. Sie werden in einem Moment wieder korrekt sein. Gerade eben sind sie veraltet. Jedes System hat irgendwo veraltete Daten. Die Frage ist nicht, ob Daten veraltet sein können, sondern wie veraltet akzeptabel ist. Millisekunden? Sekunden? Minuten? Stunden? Die Antwort hängt vom Anwendungsfall ab, und sie lautet selten „niemals“.

Die bequeme Lüge der starken Konsistenz

Es gibt noch etwas, das sich in der Softwareentwicklung hartnäckig hält: Die Behauptung, eine relationale Datenbank sei immer konsistent. Transaktionen garantieren es. ACID garantiert es. Nach dem Commit sind die Daten da, und jeder sieht sie. Das stimmt allerdings nur innerhalb einer einzelnen Datenbankinstanz, für eine einzelne Abfrage, in einem einzelnen Moment. So funktionieren reale Systeme nicht.

Wer Read-Replicas einsetzt, akzeptiert bereits, dass Leseoperationen veraltete Daten liefern können. Wer einen Cache verwendet, akzeptiert, dass die gecachten Daten zum Zeitpunkt des Lesens nicht mehr aktuell sein müssen. Wer eine mobile App betreibt, akzeptiert, dass die Anzeige auf dem Gerät den Stand der letzten Synchronisation zeigt, nicht den aktuellen. Und wer HTML serverseitig rendert, akzeptiert, dass die Seite zum Zeitpunkt der Auslieferung bereits veraltet sein kann.

In dem Moment, in dem Daten die Datenbank verlassen, beginnen sie zu altern. Bis sie den Bildschirm einer Nutzerin oder eines Nutzers erreichen, sind sie bereits ein Schnappschuss der Vergangenheit. Die Kundin sieht „Bestellung bestätigt“, aber das Lagersystem hat den Auftrag noch nicht verarbeitet. Der Kunde sieht „3 Stück auf Lager“, aber jemand anders hat gerade zwei davon in den Warenkorb gelegt. Das ist kein Fehler. Das ist die Funktionsweise verteilter Systeme. Und jedes System mit einer Bedienoberfläche ist ein verteiltes System, denn das Endgerät ist ein eigener Knoten, das Netzwerk ist unzuverlässig, und zwischen Anfrage und Antwort vergeht Zeit.

Ich begegne in meiner Beratungsarbeit regelmäßig Teams, die überzeugt sind, ihre Systeme seien stark konsistent. Bei genauerem Hinsehen zeigt sich fast immer, dass die Konsistenz an der Datenbankgrenze endet. Dahinter beginnt eine Welt aus Caches, Replikas, Message-Queues und gerenderten Oberflächen, in der Daten bereits veraltet sind, bevor sie ankommen. Das System ist längst eventually consistent. Es gibt nur niemanden, der das ausspricht.

Konsistenz vor dem Computer

Eventual Consistency ist kein Phänomen, das mit verteilten Softwaresystemen entstanden ist. Sie ist ein Grundproblem der physischen Welt, und Unternehmen haben seit Jahrhunderten Wege gefunden, damit umzugehen.

Man stelle sich eine Firma mit zwei Vertriebsbüros in verschiedenen Städten vor, zu einer Zeit, als das Telefon das schnellste Kommunikationsmittel war. Beide Büros verkaufen aus demselben Lagerbestand. Eine Kundin in München möchte die letzte Einheit eines Produkts kaufen. Ein Kunde in Hamburg möchte dieselbe Einheit kaufen. Keiner der beiden Vertriebsmitarbeiter weiß, was der andere gerade macht.

Wie haben Unternehmen dieses Problem gelöst? Nicht durch perfekte Echtzeitsynchronisation. Sie haben akzeptiert, dass Konflikte auftreten werden, und Prozesse entwickelt, um sie zu behandeln. Sie haben überbucht und sich entschuldigt. Sie haben Sicherheitsbestände geführt. Sie haben im Lager angerufen, bevor sie eine Lieferung zugesagt haben. Sie haben enttäuschte Kundinnen und Kunden kompensiert. Sie haben Risiken gemanagt, nicht Konsistenz.

Das gleiche Produkt, das gleiche Problem, nur mit Stift und Papier statt mit Datenbanken. Keine Technologie der Welt kann diese grundlegende Herausforderung eliminieren: zwei Personen, zwei Orte, eine Ressource, unvollständige Information. Die Naturgesetze garantieren, dass Information Zeit braucht, um sich auszubreiten. Perfekte Synchronisation ist nicht nur schwierig. Sie ist unmöglich.

Das Interessante daran ist, dass diese analogen Prozesse oft erstaunlich gut funktioniert haben. Nicht weil sie Inkonsistenzen verhindert hätten, sondern weil sie Strategien für den Umgang mit ihnen entwickelt hatten. Die Buchhaltung glich am Ende des Tages die Bestände ab. Der Vertrieb rief im Zweifelsfall im Lager an. Und wenn doch einmal zwei Kunden dasselbe Produkt zugesagt bekamen, gab es ein Gespräch, eine Entschuldigung und eine Lösung. Der Geschäftsprozess war auf Konflikte vorbereitet, weil niemand auf die Idee gekommen wäre, sie für unmöglich zu erklären.

Wenn ich mit Teams über Eventual Consistency spreche, hilft dieser historische Blick oft mehr als jedes Architekturdiagramm. Er verschiebt das Problem aus der technischen Ecke in die geschäftliche, wo es hingehört. Die Frage lautet nicht: Wie verhindern wir Inkonsistenz? Sie lautet: Wie gehen wir mit ihr um?

Die richtigen Fragen stellen

Wenn Entwicklerinnen und Entwickler über Eventual Consistency diskutieren, stellen sie häufig die falsche Frage. Sie fragen: Ist Eventual Consistency hier akzeptabel? Das rahmt Konsistenz als binäre Eigenschaft, als hätte man sie oder hätte sie nicht.

Die richtigen Fragen sind anders: Wie häufig tritt ein Konflikt tatsächlich auf? Wenn zwei Nutzerinnen oder Nutzer gleichzeitig den letzten Artikel kaufen wollen: Passiert das einmal am Tag? Einmal im Monat? Einmal im Jahr? Die Häufigkeit entscheidet darüber, ob ein Konflikt ein reales Problem ist oder eine theoretische Sorge. Was kostet ein Konflikt? Ist die Konsequenz eine enttäuschte Kundin? Eine Rückerstattung? Ein manueller Eingriff? Ein rechtliches Problem? Die Kosten bestimmen, wie viel Aufwand die Vermeidung rechtfertigt. Und was kostet die Vermeidung? Stärkere Konsistenzgarantien sind nicht kostenlos. Sie erfordern Koordination, also Latenz. Sie erfordern Sperren, also geringeren Durchsatz. Sie erfordern Infrastruktur, also Geld.

Das sind betriebswirtschaftliche Fragen, keine Ingenieursfragen. Das Entwicklungsteam kann erklären, was technisch möglich ist und was jede Option kostet. Aber die Entscheidung über das akzeptable Risiko gehört ins Business. Ein Bezahlsystem und ein Social-Media-Feed haben unterschiedliche Toleranzen. Eine Patientenakte und ein Warenkorb haben unterschiedliche Anforderungen. Der Kontext bestimmt die Antwort.

Genau deshalb gehören Diskussionen über Eventual Consistency nicht ausschließlich in Technik-Meetings. Das Team mag starke Meinungen über technische Korrektheit haben, weiß aber vielleicht nicht, dass die Fachabteilung eine Verzögerung von einer Sekunde bereitwillig akzeptieren würde, wenn dafür die Infrastrukturkosten sinken. Oder es weiß nicht, dass ein bestimmter Anwendungsfall regulatorische Anforderungen hat, die stärkere Garantien verlangen. Das Gespräch braucht beide Perspektiven.

Alltagsbeispiele zeigen, wie selbstverständlich Eventual Consistency bereits ist. Paketverfolgung zeigt einen Status, der vor Stunden erfasst wurde. Das Paket wurde gescannt, als es das Sortierzentrum verlassen hat. Seitdem ist es unterwegs, möglicherweise bereits zugestellt. Die angezeigte Information ist veraltet, und das stört niemanden, weil ein ungefährer Überblick über den Fortschritt ausreicht. Bestandsanzeigen in Online-Shops sind ein ähnlicher Fall. „Nur noch 3 auf Lager“ war korrekt, als die Seite gerendert wurde. Inzwischen hat vielleicht jemand eines gekauft. Vielleicht hat jemand eines in den Warenkorb gelegt, ohne zu bestellen. Die Zahl ist ein Hinweis, keine Garantie. Und das ist akzeptabel, weil der Checkout-Prozess den Grenzfall abfängt, in dem der Artikel tatsächlich vergriffen ist.

Besonders aufschlussreich ist das Beispiel der Fluggesellschaften. Airlines überbuchen bewusst, weil sie wissen, dass ein Teil der Passagiere nicht erscheinen wird. Das Buchungssystem akzeptiert mehr Reservierungen, als Sitzplätze vorhanden sind. Wenn doch alle erscheinen, wird das Problem am Gate gelöst: Kompensation, Umbuchung, Upgrade. Das System ist darauf ausgelegt, Konflikte zu akzeptieren und sie nachträglich zu lösen. Das ist kein Versagen der Konsistenz. Es ist eine Geschäftsstrategie, die jedes Jahr Millionen von Flügen mit freien Sitzen füllt, die sonst leer geblieben wären.

All diese Systeme funktionieren. Ihre Nutzerinnen und Nutzer beschweren sich nicht, weil das Konsistenzfenster kurz genug ist oder weil der Geschäftsprozess die Ausnahmen elegant abfängt. Das Ziel war nie perfekte Konsistenz. Das Ziel war ausreichende Konsistenz.

Der Geldautomat, der weiterarbeitete

Unter den vielen Beispielen, die ich in Gesprächen über Eventual Consistency verwende, ist eines besonders aufschlussreich, weil es die Perspektive komplett umdreht.

Geldautomaten sind normalerweise online und mit den Systemen der Bank in Echtzeit verbunden. Bei einer Abhebung prüft der Automat den Kontostand, verifiziert die Deckung und gibt das Geld aus. Einfach und konsistent. Doch was passiert, wenn die Netzwerkverbindung ausfällt und der Automat offline geht?

Die meisten Entwicklerinnen und Entwickler, denen ich diese Frage stelle, antworten: „Der Automat muss den Betrieb einstellen. Keine Verbindung bedeutet keine Kontostandsprüfung. Keine Prüfung bedeutet mögliche Überziehungen. Also abschalten, bis die Verbindung wiederhergestellt ist.“ Das ist die naheliegende, die sichere, die technisch korrekte Antwort. Es ist aber auch die falsche.

Man stelle sich einen prominenten Millionär vor, der an einem Geldautomaten steht und 50 Euro abheben möchte, nur um zu erfahren, dass der Automat außer Betrieb ist. Die Schlagzeile am nächsten Tag: „Bank lässt Topkunden wegen Netzwerkproblem im Regen stehen.“ Das ist keine Schlagzeile, die eine Bank gebrauchen kann. Der Reputationsschaden übersteigt jedes Überziehungsrisiko bei einer Kleinbetragabhebung um ein Vielfaches.

Was machen Banken also tatsächlich? Der Automat arbeitet weiter, auch offline. Aber mit intelligentem Risikomanagement. Die meisten Ausfälle sind kurz: Die Verbindung bricht für wenige Minuten ab und stellt sich dann von selbst wieder her. Bis jemand etwas bemerkt, hat sich das Problem bereits gelöst. Die meisten Menschen heben zudem nur Geld ab, wenn sie wissen, dass sie es haben. Niemand möchte die Peinlichkeit erleben, an einem Geldautomaten mit einer Schlange hinter sich abgelehnt zu werden. Diese Selbstselektion reduziert das Überziehungsrisiko erheblich. Und für den Fall, dass die Verbindung länger ausfällt, begrenzt die Bank den maximalen Abhebungsbetrag im Offline-Modus.

Doch der eigentlich interessante Punkt liegt woanders. Wenn jemand im Offline-Modus sein Konto tatsächlich überzieht, hat die Bank zwei Möglichkeiten, die Situation zu rahmen. Erste Variante: „Kunde nutzte Systemschwachstelle während Netzwerkausfall.“ Das klingt nach einem Sicherheitsvorfall. Zweite Variante: „Bank zeigte Flexibilität und half Kunden trotz technischer Schwierigkeiten.“ Das klingt nach exzellentem Kundenservice. Und nebenbei: Die Bank berechnet Überziehungszinsen. Der Kunde, der 50 Euro abgehoben hat, die er nicht hatte, zahlt sie zurück, mit Aufschlag. Die Bank hat eine technische Einschränkung in eine Einnahmequelle verwandelt.

Das ist es, was fachliches Denken über Konsistenz bedeutet. Die Entwicklerin sieht ein Konsistenzproblem und will es um jeden Preis verhindern. Die Geschäftsseite sieht eine Risiko-Ertrags-Rechnung und findet eine Lösung, die besser ist als sowohl „immer konsistent“ als auch „immer verfügbar“. Die beste Antwort lag nicht im Engineering-Meeting. Sie lag im Business-Meeting.

Das Verstecken ist das eigentliche Risiko

Die Gefahr liegt nicht in Eventual Consistency. Sie liegt darin, so zu tun, als gäbe es sie nicht.

Wer sein System für stark konsistent hält, entwirft keine Kompensationslogik. Wer keine Konflikte erwartet, baut keine Konfliktbehandlung. Wer keine veralteten Daten einplant, gestaltet keine Benutzererfahrung, die damit umgehen kann. Und wenn dann die Race Condition doch eintritt, wenn der Cache im falschen Moment veraltete Daten liefert, wenn die Replica-Verzögerung zu einer sichtbaren Inkonsistenz führt, gibt es keinen Plan. Das System versagt auf eine Weise, die niemand vorhergesehen hat, weil sich niemand die Mühe gemacht hat, sie vorherzusehen.

Wer Eventual Consistency dagegen anerkennt, entwirft dafür. Man denkt darüber nach, was passiert, wenn Daten veraltet sind. Man baut idempotente Operationen, die gefahrlos wiederholt werden können. Man schafft Kompensationsmechanismen für den Fall, dass etwas schiefgeht. Man kommuniziert Unsicherheit gegenüber Nutzerinnen und Nutzern, statt falsche Sicherheit zu vermitteln.

In der Praxis bedeutet das konkrete Entwurfsentscheidungen. Statt „Bestellung erfolgreich“ anzuzeigen, wenn die Bestellung lediglich angenommen wurde, zeigt man „Bestellung wird verarbeitet“ und aktualisiert den Status, sobald die Verarbeitung abgeschlossen ist. Statt eine Schaltfläche nach dem Klick zu deaktivieren und auf Konsistenz zu hoffen, gestaltet man die Operation idempotent, sodass ein doppelter Klick keinen Schaden anrichtet. Statt einen Fehler zu zeigen, wenn ein Artikel zwischen Warenkorb und Checkout vergriffen ist, bietet man eine Alternative an. Das sind keine technischen Notlösungen. Das sind durchdachte Benutzererlebnisse, die auf einer ehrlichen Einschätzung der Systemrealität basieren.

Die deutsche Fehlübersetzung ist dabei versehentlich tiefgründig. „Eventuell konsistent“ klingt bedrohlich, weil Unsicherheit bedrohlich klingt. Aber Unsicherheit ist die Realität verteilter Systeme. Die Wahl besteht nicht zwischen Sicherheit und Unsicherheit. Sie besteht zwischen eingestandener und versteckter Unsicherheit. Das eine führt zu robusten Systemen. Das andere führt zu Überraschungen.

Eventual Consistency ist keine Einschränkung, die es zu überwinden gilt. Sie ist eine Realität, für die es zu entwerfen gilt. Ihre Systeme sind bereits eventually consistent. Die Frage ist, ob Sie für diese Realität entwerfen oder so tun, als existiere sie nicht. Und diese Frage ist keine, die ein Engineering-Team allein beantworten sollte. Sie ist eine fachliche Entscheidung. Das war sie schon immer.

(rme)

Im heutigen Beitrag werde ich eine der größten Fallstricke von C++ erläutern: reinterpret_cast. Ein anderer Titel für diesen Beitrag könnte lauten: „Das ist nicht der Cast, den du suchst!“

Meine Motivation für diesen Blogbeitrag stammt aus mehreren Schulungen und einigen Vorträgen, die ich gehalten habe. Seit C++23 gibt es in der Standardbibliothek eine neue Funktion: std::start_lifetime_as. Wenn ich Kurse mit Schwerpunkt auf eingebetteten Umgebungen unterrichte oder Vorträge mit diesem Schwerpunkt halte, habe ich begonnen, std::start_lifetime_as in das Material aufzunehmen. Mit einem interessanten Ergebnis.

Das Feedback, das ich bekomme, lautet in etwa:

• Warum benötige ich std::start_lifetime_as, ich habe doch schon reinterpret_cast?
• Warum kann ich reinterpret_cast nicht verwenden?

Wer noch nie von start_lifetime_as gehört hat, findet weitere Informationen in meinem englischen Artikel „The correct way to do type punning in C++ – The second act“. Ich verwende folgendes Beispiel daraus:

struct ConfigValues {
  uint32_t                  chksum;
  std::array values;
};

bool ProcessData(std::span bytes)
{
  if(bytes.size() < sizeof(ConfigValues)) { return false; }

  // #A
  ConfigValues* cfgValues = reinterpret_cast(bytes.data());

  return HandleConfigValues(cfgValues);
}

Die Idee hier ist, eine Reihe von rohen Bytes in eine bekannte Struktur umzuwandeln – hier mit dem Namen ConfigValues. Zusammen mit start_lifetime_as gerate ich immer öfter in Gespräche, in denen mir Leute sagen, dass der Name reinterpret impliziert, dass solcher Code wie erwartet funktionieren sollte. Die Erwartung ist, dass solcher Code frei von undefiniertem Verhalten ist und tatsächlich einen Zeiger auf ein ConfigValues-Objekt zurückgibt.

Zwar kann ich einer solchen Erwartung aufgrund des Wortlauts des Standards und des C++-Objektmodells nicht widersprechen, doch eine solche Erwartung führt zu undefiniertem Verhalten. In einer typsicheren Sprache kann ein Objekt nicht in ein anderes, nicht verwandtes Objekt konvertiert werden.

Der wichtigste Wortlaut ist [expr.reinterpret.cast § 7], der besagt:

An object pointer can be explicitly converted to an object pointer of a different type. When a prvalue v of object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_cast(static_cast(v)). [Note 5: Converting a pointer of type “pointer to T1” that points to an object of type T1 to the type “pointer to T2” (where T2 is an object type and the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value. — end note]

Zunächst einmal handelt dieser ganze Absatz von Zeigern auf Objekte und nicht von Objekten selbst. Es heißt, dass du ein ConfigValues in einen void* oder einen beliebigen anderen Datentyp konvertieren kannst, der ein Objekttyp ist. Ein Objekttyp ist alles außer einem Funktionstyp, einem Referenztyp und void.

Weiter unten in der Anmerkung bestätigt der Standard ausdrücklich, dass du einen Rundlauf durchführen kannst. Zum Beispiel:

ConfigValues  cfg{};
ConfigValues* val{&cfg};
void*         typeErased         = reinterpret_cast(val);
ConfigValues* roundTripBackToVal = reinterpret_cast(typeErased);

Dies ermöglicht Konstrukte, die sogenannte Typlöschung (Type Erasure) nutzen, wie std::any. Du kannst einen Alias eines anderen Zeigertyps erhalten.

Konvertierung nur für den Zeiger

In diesem Absatz ist von einer Konvertierung des Objekts selbst keine Rede. Nur den Zeiger kann man konvertieren.

Im Sinne des C++-Objektmodells muss eine Anwendung ein gültiges Objekt erstellen (und später zerstören). Aber alles, was jemals erstellt wurde, ist ein ConfigValues-Objekt. reinterpret_cast ist ein Werkzeug, das es ermöglicht, einen Zeiger eines anderen Typs zu speichern. Sobald du ihn verwenden möchtest, musst du den Zeiger wieder in seinen ursprünglichen Typ zurückkonvertieren.

Nehmen wir einmal an, reinterpret_cast würde so funktionieren, wie manche Leute es erwarten:

struct Apple {
  int x;
};

struct Orange {
  int y;
};

Apple*  grannySmith{new Apple{4}};
Orange* bali{reinterpret_cast(grannySmith)};  // #A

int y = bali->y;
int x = grannySmith->x;

Nach den Regeln von C++ muss ein Objekt erstellt und zerstört werden. Wenn #A ein Objekt erstellen würde, müsste es das grannySmith-Objekt zerstören. Was überraschend wäre. Dann hättest du keine Möglichkeit, eine Typlöschung wie std::any zu implementieren, da das Speichern eines gelöschten Typs void* das ursprüngliche Objekt aus Sicht der abstrakten Maschinerie von C++ zerstören würde. Das würde dem Compiler ermöglichen, verschiedene andere Optimierungen vorzunehmen, die das Programm zum Absturz bringen würden.

Mit reinterpret_cast hast du eine Möglichkeit, ein Objekt A als einen anderen Typ B zu aliasieren, jedoch ohne das Recht, jemals über diesen Zeiger auf ein B-Objekt zuzugreifen. Andererseits erstellt start_lifetime_as implizit ein B-Objekt am Zielort des Zeigers A, während gleichzeitig die Lebensdauer von A beendet wird.

Ein Objekt ins Leben rufen

Meist will man in diesen Situationen ein Objekt eines anderen Typs zum Leben erwecken. Und genau dafür ist std::start_lifetime_as gedacht.

Wenn du std::start_lifetime_as auf einen Zeiger anwendest, versteht die abstrakte Maschine, dass du ein neues Objekt dieses Typs erstellst. Im Gegensatz zu einem Aufruf von new oder einem Stack-Objekt wird kein Konstruktor ausgeführt. Alles geschieht nur innerhalb des C++-Objektmodells.

Es gibt noch eine weitere Funktion von std::start_lifetime_as: Wenn es die Lebensdauer eines neuen Objekts startet, wird die Lebensdauer der Quelle automatisch beendet, wiederum ohne einen tatsächlichen Destruktor aufzurufen. Das ist hier entscheidend.

Wenn ich std::start_lifetime_as auf mein vorheriges Beispiel anwende, sieht die korrekte Implementierung wie folgt aus:

struct Apple {
  int x;
};

struct Orange {
  int y;
};

Apple*  grannySmith{new Apple{4}};
Orange* bali{std::start_lifetime_as(grannySmith)};  // #A

int y = bali->y;

grannySmith = std::start_lifetime_as(bali);  // #B
int x       = grannySmith->x;

Der Code in #B startet die Lebensdauer des Zeigers erneut als Apple-Objekt.

Wichtigste Erkenntnisse

Mit reinterpret_cast erhältst du nur eine Zeigerkonvertierung. Du darfst diesen neuen Zeiger nicht verwenden, um auf ein Objekt des Typs zuzugreifen.

Wenn du die Lebensdauer eines Objekts starten möchtest, um auf Daten als neuen Typ zuzugreifen, benötigst du std::start_lifetime_as.

(rme)

Appwrite 1.9.0 ist da und unterstützt nun MongoDB, feinere Sicherheitsmechanismen und gezieltere Realtime-Funktionen. Hinzu kommen ein ausgebauter Compute-Bereich und zahlreiche Performance-Verbesserungen.

Bei Appwrite handelt es sich um eine quelloffene Backend-as-a-Service-Plattform (BaaS), die Authentifizierung, Datenbank, Storage, Serverless Functions und Realtime-Kommunikation in einem Paket für den Eigenbetrieb bündelt. Damit richtet sie sich an Teams, die mehr Kontrolle über ihre Backend-Infrastruktur behalten wollen, als es klassische Cloud-BaaS-Dienste erlauben.

MongoDB und Datenbank-Feinschliff

Die zentrale Neuerung: Appwrite unterstützt jetzt MongoDB als Datenbank-Backend. Damit steht neben dem bisherigen TablesDB-Modell erstmals eine dokumentenorientierte Alternative bereit. Entwickler können so dynamische Datenstrukturen abbilden – etwa Event- oder Log-Daten mit variierenden Feldern –, ohne vorher ein Schema anzupassen.

Ferner ergänzt Version 1.9.0 neue String-Typen wie mediumtext und longtext, unterstützt 64-Bit-Integer und zeigt den Speicherverbrauch einzelner Collections an. Dokumentlisten lassen sich zudem mit konfigurierbarer TTL cachen, was bei häufig abgefragten Datenbeständen die Datenbanklast senkt.

Neue Admin-APIs

Administratoren erhalten mehrere neue Schnittstellen: Eine Webhooks-API verwaltet Ereignisbenachrichtigungen zentral. Eine Schedules-API gibt Einblick in geplante Aufgaben und stellt Steuerungsfunktionen bereit. Neu ist auch eine Nutzer-Impersonation (User Impersonation). Damit kann sich ein Admin als ein bestimmter Nutzer anmelden, um Fehler direkt aus dessen Perspektive nachzuvollziehen. Projektvariablen lassen sich jetzt gezielt als öffentlich markieren, etwa um Konfigurationswerte ans Frontend durchzureichen.

Die Realtime-Schnittstelle arbeitet nun gezielter. Clients definieren Subscriptions mit Query-Filtern und empfangen nur noch passende Ereignisse statt sämtlicher Änderungen in einer Collection. Ein Client könnte so ausschließlich Updates für eine bestimmte Nutzer-ID abonnieren. Appwrite liefert außerdem Metriken zu Verbindungen, Nachrichtenaufkommen und Bandbreite.

Feinere Zugriffskontrolle

API-Keys lassen sich ab Version 1.9.0 ressourcenbezogen einschränken. Ein Key kann etwa Lesezugriff auf den Storage erhalten, ohne gleichzeitig die Benutzerverwaltung freizuschalten. JWT-Laufzeiten sind individuell konfigurierbar. Verbesserungen bei CORS, OAuth und Multi-Domain-Support erleichtern Setups mit mehreren Frontends.

Im Serverless-Bereich trennt Appwrite jetzt Build- und Runtime-Ressourcen. Wer rechenintensive Builds mit einer schlanken Runtime kombinieren muss, kann beides unabhängig dimensionieren. Eigene Startkommandos, automatisches Aufräumen alter Deployments und verwaister Ausführungen sowie saubere Worker-Shutdowns sollen den Betrieb stabiler machen.

Storage, Migration und SDKs

Dateien lassen sich jetzt einzeln mit Verschlüsselungs- und Komprimierungsparametern versehen. Listenabfragen geben den gesamten Speicherverbrauch zurück. Neue Migrationstools übertragen Sites und Messaging-Ressourcen zwischen Appwrite-Instanzen. Hinzu kommen ein offizielles Rust-SDK, ein Plugin für die KI-gestützte IDE Cursor sowie ein Agent Skills SDK, das die Integration von KI-Agenten erleichtern soll.

Unter der Haube haben die Entwickler die Architektur auf die modulare Utopia-Plattform umgestellt. Der bisherige Proxy-Container entfällt, Traefik wird direkt angesprochen. Sparse Updates senden nur noch geänderte Attribute, Shared-Memory-Caching via Swoole Tables ersetzt den bisherigen Pro-Worker-Cache und vorverarbeitete Queries beschleunigen häufig genutzte Pfade. Swoole ist eine PHP-Erweiterung für asynchrone Programmierung, die hier für effizientes Shared-Memory-Caching genutzt wird. Diverse Memory Leaks in der Webhook-, Statistik- und Event-Verarbeitung haben die Entwickler behoben.

Upgrade

Appwrite 1.9.0 setzt ein Upgrade von Version 1.8.1 voraus und erfordert eine Datenbankmigration. Diese lässt sich über den neuen Web-Installer, das CLI-Flag --migrate oder manuell per docker compose exec appwrite migrate anstoßen.

Alle Informationen zu Appwrite 1.9.0 finden sich in den Release Notes auf GitHub.

(fo)