De una latencia de varios días a datos casi en tiempo real: la actualización del canal de datos de Figma

Figma ha crecido rápidamente en los últimos cinco años, incluyendo el lanzamiento de FigJam en 2021, Dev Mode en 2023, Figma Make en 2025, y la localización completa para atender a los mercados brasileño, japonés, español y coreano, pero ese crecimiento conlleva retos. A medida que nuestra base de usuarios se ha ampliado, también lo ha hecho el volumen y la complejidad de los datos que nuestra plataforma genera cada día.

El año pasado, compartimos la historia interna de cómo nuestro equipo de bases de datos escaló horizontalmente nuestras bases de datos relacionales en línea. Pero nuestro sistema de sincronización heredado, responsable de transferir datos de nuestras bases de datos en línea a nuestro almacén analítico, que alimenta datos empresariales críticos, incluidos los KPI más importantes de la empresa, tenía dificultades para mantenerse al día.

Creamos nuestro primer proceso de sincronización heredado en 2020, y la arquitectura era sencilla: una tarea cron diaria ejecutaba una simple consulta SELECT * FROM <TABLE>, subía los datos resultantes a S3 e importaba esos datos a Snowflake.

Al principio, esto funcionaba bien. Sin embargo, a medida que las tablas aumentaban de tamaño y se realizaban más inserciones, las limitaciones del sistema se hicieron evidentes. En 2023, las tareas de sincronización diarias tardaban alrededor de seis horas en completarse y teníamos que mantener réplicas de bases de datos adicionales para dar soporte a las exportaciones diarias. Nuestras tablas más grandes experimentaban tiempos de sincronización de varios días o más.

Con el tiempo, se hizo casi imposible sincronizar nuestros datos en un plazo razonable, lo que dificultó enormemente nuestra capacidad para analizar los datos y tomar decisiones informadas.

Evaluamos tres soluciones:

• Mantener nuestro proceso de sincronización heredado: esto se volvió rápidamente insostenible, debido tanto a los retrasos en la sincronización como al hecho de que mantener réplicas adicionales de la base de datos generaba millones de dólares en costes innecesarios cada año.
• Añadir paralelismo como una solución rápida: consideramos añadir paralelismo, lo que habría permitido que el proceso de sincronización realizara operaciones de forma simultánea, pero esto resultó no ser escalable.
• Revisar por completo el proceso de sincronización de datos: esto requeriría una mayor inversión durante un periodo de tiempo más largo, pero sería el enfoque más escalable y el que más probabilidades tendría de perdurar a medida que Figma sigue creciendo.

Al analizar las opciones, nuestra elección quedó clara: cambiamos nuestro enfoque hacia el largo plazo y comenzamos a trabajar en la sincronización incremental, una solución que prometía resultados sostenibles y eficientes.

Comprar o crear

Para que funcione, la sincronización incremental requiere compatibilidad con instantáneas de tablas de bases de datos, flujos de captura de datos modificados (CDC) y fusión incremental. Cuanto más analizábamos el potencial de la sincronización incremental, más nos dábamos cuenta de que tendríamos que crearla nosotros mismos. Consideramos la posibilidad de comprar una solución integral patentada, pero ninguna opción satisfacía nuestras necesidades en términos de flexibilidad, coste y escala.

Flexibilidad: muchas de las herramientas genéricas compatibles con SQL que encontramos no utilizaban de manera eficaz las capacidades específicas del proveedor. Las API de Amazon Relational Database Service (RDS) para PostgreSQL, por ejemplo, nos habrían permitido crear instantáneas directamente sin la sobrecarga que supone mantener una réplica de la base de datos independiente, pero las opciones genéricas no aprovechaban esta ventaja. Si optáramos por una solución de proveedor, no tendríamos la flexibilidad necesaria para optimizar nuestro flujo de trabajo con la tecnología que ya tenemos.

Coste: muchas opciones también habrían supuesto un coste adicional significativo a nuestra escala. Cuando calculamos el precio de nuestras opciones, estimamos que las soluciones propietarias costarían entre cinco y diez veces más que una solución interna.

Escalabilidad: el coste podría haber merecido la pena si esas herramientas fueran escalables, pero descubrimos que muchas de ellas no lo eran lo suficiente para nuestras necesidades actuales y cada vez mayores. Creamos nuestro proceso de sincronización heredado en 2020, y Figma sigue creciendo. Al desarrollarlo internamente, nos aseguramos de poder innovar rápidamente en respuesta a necesidades futuras.

Crear y combinar componentes de nivel inferior

Al construir una canalización personalizada, pudimos encontrar y combinar componentes de bajo nivel, ya fueran servicios de código abierto o gestionados, que se alineaban con nuestros requisitos exactos de infraestructura (y la experiencia de nuestro equipo).

Para las instantáneas, utilizamos Amazon RDS, que puede exportar a S3 para copias iniciales de tablas. Para la CDC, utilizamos Kafka Connect, que ofrece transmisión eficiente una vez integrado con un conector de Snowflake y alojado en Amazon Managed Streaming for Apache Kafka (MSK). Para la fusión incremental, implementamos una lógica de fusión personalizada a través de procedimientos almacenados de Snowflake y procesos automatizados mediante tareas de Snowflake.

Crear una nueva arquitectura de canalización

Con cada nuevo proyecto, definimos los principios de diseño que guían el trabajo y dan forma a nuestros objetivos y decisiones. Para este proyecto, definimos cuatro principios:

• Latencia: reducir el tiempo de sincronización de datos de principio a fin.
• Coste: reducir los costes y mantenerlos bajos aunque seguimos creciendo.
• Cumplimiento: cumplir con toda la normativa pertinente en materia de datos.
• Integridad de los datos: utilizar flujos de trabajo que garanticen que los datos sigan siendo precisos, completos, coherentes y fiables a lo largo de todo el ciclo de vida.

En última instancia, estos principios se tradujeron en un canal de datos rediseñado que logra una sincronización incremental a través de dos flujos de trabajo fundamentales: un flujo de trabajo de arranque y un flujo de trabajo de validación. El flujo de trabajo de arranque integra nuevas tablas en el canal, y el flujo de trabajo de validación verifica la exactitud de los datos a medida que estos fluyen al canal. Juntos, estos dos flujos de trabajo garantizan que los datos fluyan de manera eficiente y se mantengan lo más coherentes y correctos posible.

Flujo de trabajo de arranque

Nuestro proceso de incorporación para integrar nuevas tablas en el canal de sincronización consta de los siguientes pasos automatizados y claramente definidos:

1. El servicio de CDC existente captura la nueva tabla de Postgres y publica eventos en los temas por tabla de Kafka. Hemos automatizado este paso utilizando nuestro servicio de CDC interno existente y lo hemos integrado con la topología del sistema de base de datos.
2. Transferimos la última instantánea diaria de la base de datos a S3 utilizando el proceso de exportación de instantáneas de Amazon RDS (que puede ser largo dependiendo del tamaño de la tabla).
3. Una vez que la instantánea se ha exportado correctamente a S3, la consulta COPY INTO <table> de Snowflake importa los datos de S3 a las tablas base dedicadas por entidad de Snowflake.
4. Un conector Snowflake Sink dentro de MSK Connect transmite el contenido de los temas de Kafka a las tablas de CDC por entidad de Snowflake, asegurando que el desplazamiento inicial de Kafka sea anterior a la marca de tiempo de la instantánea.
5. Programamos una tarea de Snowflake para ejecutar periódicamente un procedimiento almacenado MERGE personalizado que hemos desarrollado.
6. Cuando la sincronización se pone al día con los cambios recientes, creamos una vista sencilla sobre la tabla base para facilitar las consultas de los usuarios, y con eso se completa la incorporación.

Implementamos una capacidad de rearranque sin tiempo de inactividad, que es crucial para gestionar eventos como la evolución del esquema. Para ello, versionamos todos los artefactos de arranque excepto la vista final orientada al usuario, ya que esto permite un arranque paralelo sin interrumpir las operaciones en tiempo real. La promoción a la nueva versión se produce de forma fluida mediante un paso de actualización de vista atómica.

Flujo de trabajo de validación

A pesar de los diseños sólidos, los canales de datos corren inevitablemente el riesgo de sufrir corrupción de datos debido a fallos parciales, componentes mal configurados, bugs de software o anomalías inesperadas en los datos de origen. Pueden surgir problemas en diversos puntos, desde las exportaciones de instantáneas y las capturas de eventos de CDC hasta las fusiones incrementales, y pueden provocar inconsistencias silenciosas en los datos o resultados analíticos incorrectos si no se verifican.

Por lo tanto, otro aspecto crítico de la arquitectura es un flujo de trabajo de validación sólido dedicado a verificar la exactitud de los datos, que funciona de la siguiente manera:

1. Clona la tabla base activa, que designamos como la fuente.
2. Ejecuta el flujo de trabajo de arranque, que configuramos explícitamente para exportar las tablas base y de CDC a un esquema temporal, etiquetado como el objetivo. Esto se ejecuta sin iniciar fusiones automatizadas.
3. Alinea las tablas base de origen y destino en posiciones idénticas en el tiempo utilizando los datos CDC exportados para garantizar la coherencia.
4. Realiza comparaciones precisas, celda por celda, entre las tablas de origen y destino.
5. Genera resultados detallados a partir de estas comparaciones e integra los resultados en nuestros sistemas de supervisión y alerta.

Esta validación rigurosa, a nivel de celda y sensible a la CDC, proporciona una confianza absoluta en la integridad de los datos, lo que mejora sustancialmente la fiabilidad antes y después del lanzamiento del servicio.

Invertir en automatización

El éxito en este caso no habría sido posible sin la automatización. El canal que creamos requería una amplia coordinación entre numerosas llamadas en red y dependencias, y necesitábamos tanto automatización ad hoc como programada para que todo funcionara correctamente.

Con AWS Step Functions, organizamos nuestra automatización en dos categorías:

Automatización de primer nivel: esta categoría incluye flujos de trabajo que podemos activar de forma manual y ad hoc. Los diseñamos para ejecutar procesos de arranque o validación indicando solo el nombre de la entidad. Una vez ejecutados, estos flujos de trabajo no requieren intervención manual a menos que la supervisión genere una alerta. Nos aseguramos de que las alertas sean lo suficientemente sonoras como para provocar una acción inmediata por parte del operador, ya sea un bug real en el canal o un falso positivo en la lógica de validación, y proporcionamos medidas claras para evitar que se repita y mantener una alta eficiencia y fiabilidad operativa.

Automatización de segundo nivel: esta categoría incluye flujos de trabajo que diseñamos para invocar automatizaciones de primer nivel basadas en condiciones y horarios específicos. El primer nivel realiza el trabajo pesado y el segundo nivel verifica automáticamente los estados actuales para ver si necesitamos activar una automatización de primer nivel. Estos son algunos ejemplos:

• Un flujo de trabajo de control comprueba periódicamente, cada pocas horas, si hay nuevas entidades disponibles para su incorporación o rearranque.
• Un flujo de trabajo de validación inicia automáticamente flujos de trabajo de validación para cada tabla semanalmente.
• Un flujo de trabajo de invalidación realiza operaciones de rearranque semanales en cada tabla para garantizar la integridad de los datos.
• Un flujo de trabajo de limpieza limpia rutinariamente cada semana los artefactos potencialmente huérfanos, manteniendo un entorno ordenado y eficiente.

Adoptamos un enfoque agresivo para las pruebas: una rigurosa rutina de automatización en nuestro entorno de pruebas rearranca automáticamente todas las tablas cada semana para simular y descubrir de forma proactiva posibles problemas. Esto resultó muy útil cuando identificamos un modo de fallo grave tan solo una semana después de comenzar las pruebas. Este problema habría provocado una interrupción en todo el sitio que habría durado al menos veinte minutos si hubiera llegado a la fase de producción. Al detectarlo a tiempo, garantizamos la estabilidad durante las implementaciones de producción reales.

Casos como este reforzaron nuestra convicción de que la automatización total tenía que ser nuestro objetivo principal. Incluso cuando algunos flujos de trabajo parecían difíciles o arriesgados de automatizar por completo, avanzamos progresivamente hacia la automatización total, mientras implementábamos la automatización parcial de forma provisional. Este enfoque nos permitió mejorar constantemente la fiabilidad del sistema y reducir los gastos generales operativos con el tiempo.

Las operaciones se han mantenido fluidas y no se han producido incidentes importantes durante y después del lanzamiento.

Nuevas funciones para obtener mejores datos en tiempo real

A medida que hicimos la transición a esta nueva arquitectura, nuestras capacidades mejoradas de flexibilidad y automatización dieron paso a oportunidades para desarrollar nuevas funciones. Tres mejoras clave mejoraron significativamente nuestra experiencia de usuario y la productividad de los desarrolladores.

Actualización configurable

Basándonos en los comentarios de los usuarios finales, establecimos la frecuencia de fusión predeterminada cada tres horas para poder equilibrar la frescura de referencia de todas las entidades con los costes de procesamiento de Snowflake. Además, introdujimos anulaciones configurables para las tablas que requieren actualizaciones más frecuentes. Por ejemplo, nuestro canal de facturación se benefició significativamente de las anulaciones de media hora, lo que redujo considerablemente la latencia general de extremo a extremo del canal.

Sincronización bajo demanda

Podemos activar fusiones de manera segura en cualquier momento gracias a nuestro sistema de cola de fusiones. Esta renovada seguridad nos permitió introducir una herramienta CLI amigable para el usuario que permite la sincronización de datos manual e inmediata fuera del horario automatizado regular. Esto asegura el acceso oportuno a los datos frescos de la base de datos en línea en Snowflake cuando sea necesario.

Inspección de datos CDC en Snowflake

Dado que los datos CDC ya se habían importado a Snowflake para fines internos, los pusimos a disposición de los usuarios finales interesados en obtener datos más detallados que exploraran la secuencia de cambios que condujeron al estado de una entidad, y no solo el estado actual de dicha entidad. Durante la respuesta a incidentes, esta función proporciona un entorno seguro sin conexión para depurar actividades inesperadas de escritura en la base de datos. Por ejemplo, los desarrolladores pueden realizar consultas como “recuperar todos los eventos de inserción/actualización/eliminación de correos electrónicos de los usuarios de un equipo específico durante la última semana”. Al usar también nuestra función de sincronización bajo demanda, los desarrolladores pueden consultar estos datos en Snowflake casi en tiempo casi real. Para cumplir con las políticas de retención de datos y evitar un crecimiento indefinido del almacenamiento, los datos CDC se eliminan automáticamente después de un período predefinido.

Resultados

Este proyecto requirió una importante inversión de tiempo, esfuerzo y recursos, pero el trabajo ha dado sus frutos y los resultados han superado nuestras expectativas.

Actualización de datos mejorada

Mejoramos considerablemente la actualización de los datos. Anteriormente, los datos solían tener 30 horas o más de antigüedad. Ahora, los datos tienen tres horas o menos de antigüedad, y los usuarios tienen la flexibilidad de configurar la actualización en cuestión de minutos.

Rendimiento escalable

Ahora, este canal maneja de forma fiable tablas que son más de diez veces más grandes que antes, con un rendimiento constante y predecible a medida que Figma sigue creciendo.

Productividad de los desarrolladores

Las nuevas herramientas siempre plantean la posibilidad de interrumpir el flujo de trabajo, por lo que generamos confianza en nuestro equipo con entrevistas para identificar sus necesidades e integrando la canalización con sistemas que nuestro equipo conocía bien.

Una vez completado el trabajo, pudimos demostrar un aumento significativo de la productividad de los desarrolladores gracias a la reducción de la sobrecarga operativa y al acceso casi en tiempo real a los datos en línea dentro del almacén de análisis.

Ahora los desarrolladores pueden consultar de forma segura tanto el estado actual como el historial de cambios, actualizados cada pocos minutos, y así responder más rápido a las incidencias, realizar implementaciones más seguras y obtener datos más detallados.

Rentabilidad

En la fase inicial de la implementación, dimos prioridad al soporte para bases de datos fragmentadas horizontalmente. Este soporte ofreció un alto retorno de la inversión, ya que las bases de datos fragmentadas horizontalmente tenían menos tablas, pero utilizaban más máquinas de bases de datos, cada una con su propia réplica por lotes. Ahora, este canal proporciona un ahorro anual multimillonario gracias a la optimización inteligente de la infraestructura y la utilización de los recursos, la eliminación del procesamiento redundante y la escalabilidad adaptada al crecimiento de la empresa.

Oportunidades futuras

Nuestra nueva arquitectura sienta las bases para varias oportunidades interesantes que permitirán mejorar y ampliar aún más el canal de datos.

• Incorporación totalmente automatizada: actualmente, la incorporación requiere una solicitud de extracción para añadir tablas a una lista de permitidos, generando fricciones durante el proceso de incorporación. Integrar nuestra topología de base de datos directamente en el proceso automatizaría por completo la incorporación de tablas, optimizando la experiencia del desarrollador y reduciendo la sobrecarga manual.
• Compatibilidad con tablas en momentos puntuales: podemos ofrecer la posibilidad de consultar el estado de las tablas en cualquier momento dentro de nuestro periodo de retención de CDC definido utilizando nuestros datos de CDC. Implementar esta función mejoraría significativamente las capacidades de depuración, la respuesta a incidentes y la flexibilidad analítica.
• Modelos posteriores actualizados de forma incremental: muchos de nuestros modelos analíticos posteriores siguen creándose mediante procesos por lotes tradicionales. Nuestra nueva canalización nos permitiría actualizarlos de forma incremental, mejorando drásticamente su eficiencia y reduciendo la latencia en todo el flujo de trabajo analítico.

Esta ambiciosa transformación fue posible gracias a la increíble dedicación y esfuerzo de los miembros actuales y anteriores del equipo de infraestructura de datos de Figma: Amadeo Casas, Alex Tian, Brandon Choi, Carter Bian, David Mah, Dorothy Chen, Ebuka Akubilo, Jimmy Xie, Krish Chainani, Merry Song, Michael Wu, Peng Wang, Raunak Agnihotri, Santosh Muthukrishnan, Xinxin Dai y Zubair Saiyed.

También queremos expresar nuestro especial reconocimiento y agradecimiento a nuestros equipos de socios colaboradores: Asheesh Laroia, Dylan Visher, Gordon Yoon, Gustavo Angulo Mezerhane, Langston Dziko, Ping-Min Lin, Sammy Steele, Sean Rice y Yazad Khambata.

¡Estamos contratando ingenieros! Obtén más información sobre la vida en Figma, yexplora nuestras vacantes.