Lovable entwickelt Echtzeitdienst zur zentralen Verwaltung von Datenberechtigungen

Lovable berichtete am 9. November 2026, dass das Frontend mit der vollständigen Einführung von Lovable Realtime nicht mehr Firestore nutzte. Der eigens entwickelte Dienst zentralisiert die Berechtigungsprüfung und erreichte während eines 30-tägigen Messzeitraums einen Spitzenwert von 2,06 Millionen gleichzeitigen Abonnements.

Durch die Migration liegen Entscheidungen über Zugriffsrechte und sichtbare Felder nun im Go-Backend von Lovable. Für die KI-Plattform des Unternehmens zur App-Entwicklung bietet der Dienst eine Möglichkeit, Daten aus Firestore und Spanner zusammenzuführen und die Ansicht eines Nutzers zu aktualisieren, wenn sich entweder die zugrunde liegenden Informationen oder die Berechtigungen dieses Nutzers ändern.

Berechtigungen und Live-Daten zentral verwalten

Einige Bereiche von Lovable nutzten zuvor Firestore-Listener im Browser onSnapshot für Aktualisierungen. Der Browser erhielt vollständige Dokumente, während die Firestore-Regeln das Berechtigungsmodell der Go-API nachbilden mussten. Durch diese Architektur wurde die Offenlegung von Daten zudem zu einem Bestandteil routinemäßiger Dokumentänderungen: Wer ein Feld hinzufügte, konnte damit bestimmen, welche Daten in den Browsern der Nutzer landeten, ohne sich unbedingt dieser Folge bewusst zu sein.

Firestore-Regeln können Firebase-Daten abfragen, nicht aber Spanner. Das erschwerte die Aktualisierung von Berechtigungen für große Unternehmensgruppen, die über SCIM synchronisiert werden. SCIM überträgt Nutzer und Gruppen in einen Lovable-Arbeitsbereich. Ein vorübergehender Proxy über die Go-API für Geschäfts- und Unternehmenskunden nutzte die Berechtigungsprüfungen der API erneut. Außerdem richtete er für die Abhängigkeiten jedes Clients eigene Firestore-Listener auf der Serverseite ein. Dadurch wurden Datenströme dupliziert und Kapazitäten in einem Verbindungspool verbraucht, der auch für gewöhnliche Datenbankanfragen genutzt wurde.

Lovable verlangte, dass die Ersatzlösung mit beiden bestehenden Datenbanken funktioniert, Zugriffsrechte fortlaufend neu bewertet und den Datenstrom eines Nutzers bei entzogenen Berechtigungen auch mitten in einer Sitzung schließt. Außerdem sollten nicht autorisierte Felder zurückgehalten werden, bevor Daten den Server verließen. Nach Einschätzung des Unternehmens boten die untersuchten Transport-, Synchronisierungs- und datenbankintegrierten Lösungen diese Kombination nicht, ohne erheblichen Integrationsaufwand, einen Datenbankwechsel oder eine Replikation in Postgres zu erfordern.

Der entwickelte Go-Dienst läuft auf GKE und öffnet pro Browser-Tab eine WebSocket-Verbindung, über die mehrere Abonnements gebündelt laufen. Change-Data-Capture-Feeds leiten Änderungen aus Firestore und Spanner über eine Bridge an NATS weiter, den Nachrichtenbus des Dienstes. Für passende Abonnements werden die Ansichten neu berechnet, xxh3-128-Hashes verglichen und nur dann Änderungen gesendet, wenn sich das Ergebnis verändert. Ein einzelnes Abonnement kann Daten aus beiden Datenbanken beziehen und dabei das Berechtigungsframework der API anwenden.

Berechtigungen werden wie eine weitere reaktive Datenquelle behandelt. So können Berechtigungsänderungen unabhängig von gewöhnlichen Dokumentänderungen neue Ergebnisse auslösen. Lovable berichtete, dass die Neuberechnung nur dann erfolgt, wenn sich Felder ändern, die für Zugriffsentscheidungen relevant sind, statt bei jeder entsprechenden Dokumentaktualisierung. Dadurch seien die Neuberechnungen von Berechtigungen um etwa 84 % zurückgegangen. Der Dienst umfasst rund 40 Abonnementtypen, die von sieben Teams betreut werden, sowie typisierte Schnittstellen, gemeinsam genutzte serverseitige Abonnements und teambezogen weitergeleitete Warnmeldungen.

Schattenverkehr bestätigte die erfolgreiche Einführung

Zunächst ließ Lovable den Dienst im Schattenmodus laufen: Das Frontend durchlief den gesamten neuen Ablauf, verwarf aber die übertragenen Daten und stellte die Inhalte weiterhin anhand von Firestore dar. Der Einsatz mit echtem Datenverkehr und realistischen Datenstrukturen machte Verbindungsstürme nach Bereitstellungen, falsch klassifizierte Fehler und eine für echte Daten zu niedrige Obergrenze für die Nutzdaten sichtbar. Anschließend erhöhte ein Feature-Flag den Nutzeranteil über mehrere Tage hinweg von 1 % auf 10 %, 50 % und schließlich 100 %. Lovable zufolge kam es bei der Einführung weder zu einem Vorfall, der für Nutzer sichtbar war, noch zu einer Verschlechterung der überwachten Kennzahlen.

Da WebSocket-Verbindungen fest an einen Server gebunden sind und stundenlang bestehen können, verteilt das Hinzufügen weiterer Pods die bestehende Last nicht von selbst neu. Lovable verteilt die Last anhand der Verbindungszahl, skaliert unter Berücksichtigung der Verbindungen sowie der CPU- und Speicherauslastung und begrenzt die Verbindungen pro Pod, um erneute Verbindungswellen einzudämmen. Nach dem Wiederverbinden senden Clients einen Fingerabdruck ihres zwischengespeicherten Zustands. So kann der Server nach erneuter Prüfung der Berechtigungen bestätigen, dass die Daten unverändert sind, statt sie nochmals zu übertragen.

Der Autor des Beitrags erklärte, die Kernentwicklung habe 40 Arbeitstage mit praktischer Umsetzung in Anspruch genommen. Nachdem die Architektur und die Sonderfälle ausgearbeitet worden waren, hätten Coding-Agenten den Großteil der Implementierung übernommen. Eine Integrationsumgebung kombinierte Emulatoren für Firestore, Auth und Spanner mit einem eingebetteten NATS-Server und echten ID-Tokens, die von einem Emulator ausgestellt wurden. Damit konnten die Agenten Änderungen über den gesamten Stack hinweg testen.

Ergebnisse im Produktivbetrieb und mögliche Unterstützung für Apps

Für den Zeitraum vom 5. September bis zum 5. Oktober 2026 meldete Lovable 2,61 Milliarden Daten- und Patch-Frames, wobei fortgesetzte Steuerungs-Frames nicht mitgezählt wurden. Das Unternehmen schätzte, dass vollständige Momentaufnahmen für jedes berechnete Ergebnis 40 TB an Anwendungsnutzdaten erzeugt hätten. Deduplizierung, Delta-Übertragungen und die Wiederverwendung von Verbindungen senkten die tatsächlich gesendete Datenmenge auf 1,11 TB. Das entspricht einer geschätzten Verringerung um 97 % gegenüber diesem Ausgangswert. Die Angaben zu den Nutzdaten schließen den Protokoll- und Transportaufwand aus.

Lovable maß das Intervall zwischen einem Schreibvorgang in einer Quelldatenbank und der Versandbereitschaft eines ausgehenden Frames mit 66 Millisekunden beim p50-Wert und 249 Millisekunden beim p99-Wert. Diese Messwerte schließen Schreibvorgänge über den Socket, Netzwerkzeit und die Verarbeitung auf dem Client aus. Sie bilden daher nicht die vollständige, vom Nutzer wahrgenommene Aktualisierungszeit ab.

Lovable erklärte, dass das Unternehmen aktiv Grundbausteine für Domänenereignisse hinzufügt, damit Nutzer in Fällen, in denen sie erfahren müssen, dass etwas geschehen ist, statt einen Datensnapshot zu erhalten, entsprechend benachrichtigt werden können. Außerdem könnte der Dienst später zu einer Funktion in Apps werden, die mit Lovable erstellt wurden. Eine solche Erweiterung würde Berechtigungen, die vom Backend gesteuert werden, und Live-Ansichten in von Kunden erstellte Anwendungen bringen. Die aktuelle Bereitstellung bietet den Teams von Lovable bereits eine gemeinsame Grundlage für eine intensivere Zusammenarbeit, während sich ihre Dateninfrastruktur weiterentwickelt.