In den letzten Jahren hat Figma ein beeindruckendes Wachstum erfahren – nicht nur durch den Ausbau der Produktpalette wie FigJam, Dev Mode und Figma Make, sondern auch durch die Ausweitung der globalen Märkte, beispielsweise in Brasilien, Japan, Spanien und Korea. Dieses Wachstum birgt enorme Herausforderungen im Hinblick auf die Menge und Komplexität der täglich generierten Daten. Besonders deutlich wurde diese Problematik bei der Datenpipeline, die für den Abgleich zwischen den Online-Datenbanken und dem analytischen Data Warehouse verantwortlich ist. Während die Online-Datenbankinfrastruktur dank horizontaler Skalierung solide straffte Leistung bietet, stieß die bisherige Synchronisationsmethode an ihre Grenzen. Die zuvor eingesetzte tägliche vollständige Kopie der Daten führte zu immer längeren Verzögerungen.
Die Prozesse zogen sich über Stunden, manchmal sogar Tage hin, was die Agilität des Unternehmens bei Entscheidungen erheblich beeinträchtigte. Dabei ging es um essentielle Kennzahlen und Einblicke, die für die Geschäftsstrategie von großer Bedeutung sind. Die Engpässe machten den Wandel unausweichlich: Es musste eine neue Architektur her, die Geschwindigkeit, Kosteneffizienz und Datenintegrität nachhaltig gewährleisten konnte. Die alte Pipeline basierte auf einem einfachen und pragmatischen Ansatz: Ein Cron-Job führte eine umfangreiche SQL-Abfrage für jede Tabelle aus, die gesamten Daten wurden auf S3 (Amazon Simple Storage Service) hochgeladen und anschließend in Snowflake importiert – ein Cloud-basiertes Data Warehouse, das analytische Abfragen ermöglichte. Anfangs funktionierte dieses Vorgehen zufriedenstellend, doch mit zunehmendem Datenvolumen stiegen auch die Anforderungen.
Nicht nur wuchsen die Tabellen in ihrer Größe, auch die Anzahl der täglichen Einfügungen und Updates nahm stark zu. Um den Export überhaupt noch bewältigen zu können, entstand die Notwendigkeit, zusätzliche Datenbank-Replikate zu unterhalten, was zu massiv steigenden Betriebskosten in Millionenhöhe führte. Dies zeigte klar auf, dass weder die Performance noch die Wirtschaftlichkeit auf Dauer gesichert waren. Vor diesem Hintergrund prüfte Figma potenzielle Lösungen: Die Beibehaltung der Legacy-Synchronisation hätte bedeutet, weiterhin langwierige Verzögerungen und kostenintensive Infrastrukturanforderungen zu akzeptieren. Ein Vorschlag war, Parallelität einzuführen, um mehrere Synchronisationsprozesse gleichzeitig ablaufen zu lassen.
Diese Option stellte sich aber schnell als wenig skalierbar heraus, da bei wachsender Tabellenanzahl und Datenkomplexität die Verwaltung parallel laufender Prozesse enorme Herausforderungen verursachen würde. Die einzige wirklich nachhaltige Option war die komplette Überarbeitung des Synchronisationsmechanismus. Mit einer langfristigen Strategie sollte eine Architektur geschaffen werden, die künftig nicht nur für die Herausforderungen des aktuellen Datenwachstums geeignet ist, sondern auch zukünftige Skalierungen ohne erhebliche Mehrkosten ermöglichen kann. Der zentrale Pfeiler dieser Umgestaltung ist die Einführung der inkrementellen Synchronisation. Dieses Verfahren beruht darauf, nur die tatsächlich eingetretenen Datenänderungen seit dem letzten Update zu übertragen statt ganzer Datensätze oder sogar kompletter Tabellen.
Das Prinzip klingt simpel, ist im industriellen Maßstab aber hochkomplex umzusetzen. Durch sogenannte Change Data Capture (CDC) Mechanismen werden laufend Änderungen an der Basisdatenbank erfasst und effizient in Streaming-Formate übersetzt. Diese können dann von nachfolgenden Schritten verarbeitet und in das Data Warehouse eingespielt werden. Hierdurch reduziert sich nicht nur die Datenmenge, sondern vor allem auch die Latenzzeit bis zur Verfügbarkeit aktueller Daten erheblich. Das Ergebnis sind nahezu Echtzeit-Einblicke, die für agile Geschäftsentscheidungen essentiell sind.
Figma entschied sich bewusst gegen eine bereits fertige, proprietäre Lösung. Ihnen war klar, dass keine auf dem Markt existierende Software für ihre Anforderungen flexible Anpassungen, Kostenkontrolle und Skalierbarkeit in ausreichendem Maß bot. Insbesondere die Möglichkeit, auf vendor-spezifische Features der zugrundeliegenden AWS-Plattform zuzugreifen, war ein entscheidender Punkt. Auch der erwartete Preis für fertige Lösungen lag deutlich über den projektierten Entwicklungskosten einer maßgeschneiderten Eigenentwicklung. Somit fiel die Entscheidung auf die Entwicklung einer eigenen, modularen Pipeline, die genau auf das bestehende technische Ökosystem zugeschnitten ist.
Für die Umsetzung wurden bewährte Komponenten kombiniert: Die Basis-Snapshots der Daten kommen direkt aus Amazon RDS, wobei diese mit einem Export nach S3 den initialen Datenbestand für eine Tabelle liefern. Änderungen werden mittels Kafka Connect, betrieben auf Amazon Managed Streaming for Apache Kafka (MSK), als Datenstrom verarbeitet. Schließlich erlaubt Snowflake mittels speziell entwickelter Stored Procedures eine inkrementelle Zusammenführung (Merge) der aktuellen Daten. Automatisierte Tasks in Snowflake steuern den regelmäßig wiederkehrenden Abgleich und Konsolidierung der Daten. Dieses Gewerk erlaubt es, Daten effizient zu übertragen, inkonsistente Zustände zu minimieren und gleichzeitig Bereitstellungszeiten drastisch zu verkürzen.
Die zugrunde liegende Architektur basiert auf zwei zentralen Workflows: dem Bootstrap- und dem Validierungsworkflow. Der Bootstrap-Workflow dient zur Aufnahme neuer Tabellen in die Pipeline. Er beginnt mit der Erfassung der originalen Datenbank-Snapshots und den laufenden Change-Streams, welche gemeinsam verwendet werden, um die Datengrundlage für spätere inkrementelle Updates zu schaffen. Nach erfolgreicher Integration wird eine schlanke Sicht (View) für Nutzer bereitgestellt, die schnellen Zugriff auf aktuelle Daten ermöglicht und die Synchronisation abschließt. Besonders hervorzuheben ist die Fähigkeit, Bootstrapping mit Null Ausfallzeit durchzuführen, was durch Versionierung und atomare Updates der Nutzer-Sichten erreicht wird.
Der Validierungsworkflow fungiert als Kontrollinstrument, um die Genauigkeit und Vollständigkeit der synchronisierten Daten sicherzustellen. Fehlerhafte Prozesse oder Anomalien in den Daten könnten zu falschen Analysen und daraus resultierenden Fehlentscheidungen führen. Dies wird durch einen Prozess abgefangen, der live-Daten mit einem temporären Replikat auf Zellebene vergleicht – inklusive Abgleich der Change Data Capture-Events. So werden Fehler frühzeitig entdeckt, dokumentiert und der Betrieb entsprechend alarmiert, ohne dass Inkonsistenzen die Geschäftsanalyse beeinträchtigen. Der Erfolg dieses komplexen Systems basiert wesentlich auf intelligenter Automatisierung.
Figma nutzte AWS Step Functions, um sämtliche Abläufe sowohl ad hoc als auch zeitgesteuert orchestrieren zu können. So lassen sich teilweise kritische Synchronisationen und Validierungen nahezu ohne manuellen Eingriff ausführen. Gleichzeitig ist bei auftretenden Abweichungen eine sofortige Alarmierung und klar definierte Handlungsempfehlungen für Betreiber gewährleistet. Zudem wird durch regelmäßige, automatisierte Re-Bootstrap-Tests in einem Staging-System die Zuverlässigkeit kontinuierlich überprüft. Diese Vorsichtsmaßnahmen führten zu einem reibungslosen Betrieb ohne größere Ausfälle oder Qualitätsprobleme seit Einführung der neuen Pipeline.
Mit der neuen Flexibilität und Performance ergaben sich auch neue Möglichkeiten zur Verbesserung der Benutzererfahrung und Entwicklerproduktivität. So ermöglichten einstellbare Synchronisationsintervalle, dass unterschiedliche Tabellen je nach Anwendungsfall in variablen Fristen aktualisiert werden können – von wenigen Minuten bis zu mehreren Stunden. Zudem wurde eine on-demand Synchronisation entwickelt, mit der Daten bei akuten Bedarf schnell und sicher aktualisiert werden können. Gleichzeitig können Entwickler direkt in Snowflake tiefere Einblicke in die Datenhistorie gewinnen, indem sie die CDC-Daten auswerten. Dies unterstützt ein effizienteres Debugging sowie schnellere und sicherere Rollouts neuer Features.
Die Resultate sprechen für sich: Die Datenverzögerungen wurden von vorher häufig über 30 Stunden auf nun maximal drei Stunden reduziert, in einigen Fällen sogar deutlich weniger. Die Pipeline verarbeitet Datenmengen, die um ein Vielfaches größer sind als zuvor, ohne dabei an Performance oder Stabilität einzubüßen. Die Kosten konnten durch den Wegfall teurer Datenbank-Replikate und eine deutlich effizientere Ressourcennutzung um Millionen von Dollar pro Jahr gesenkt werden. Gleichzeitig stieg die Qualität der Analyseergebnisse, was maßgeblich zur schnelleren und besseren Entscheidungsfindung beiträgt. Entwickler profitieren von einem deutlich reduzierten operativen Aufwand und schnellen Zugriff auf aktuelle und historische Daten.
Der Blick nach vorne bleibt optimistisch: Geplant sind weitere Automatisierungen, die den Prozess des Onboardings neuer Tabellen vollständig entkoppeln und beschleunigen sollen. Auch wird überlegt, wie man zukünftig punktgenaue Zustände der Daten zu beliebigen Zeitpunkten abfragen kann – eine Funktion, die das Debugging und die Analyse erheblich erweitert. Ebenso ist die schrittweise Umstellung von traditionellen Batch-Analysen auf inkrementell aktualisierte Modelle vorgesehen, was die End-to-End-Latenz in der Analyse weiter senken dürfte. Zusammenfassend zeigt Figma mit seiner innovativen Datenpipeline, wie wichtig es ist, technische Infrastruktur kontinuierlich den wachsenden Anforderungen anzupassen. Die Kombination aus cloudbasierten Diensten, speziell entwickelter Software und automatisierter Überwachung resultiert in einer robusten, flexiblen und kosteneffizienten Lösung.
Dieses Beispiel spiegelt nicht nur den technologischen Fortschritt wider, sondern macht Figma auch fit für zukünftige Herausforderungen, um weiterhin datengetriebene Entscheidungen auf höchstem Niveau zu ermöglichen.
