Cómo el equipo de bases de datos de Figma sobrevivió para contarlo a escala

DB distribuida vs. Postgres fragmentado

• Muchos sostienen que esta es la historia clásica: empezar con una sola instancia de RDS, alcanzar los límites de escala, pasar años fragmentando; algunos dicen “simplemente usa una base de datos distribuida” desde el primer día.
• Otros replican que, entre 2012 y 2016, las opciones maduras de SQL distribuido eran limitadas, especialmente para cargas de trabajo altamente relacionales con muchas joins.
• Varios señalan que no hay comida gratis: los sistemas distribuidos añaden complejidad, coste y requieren decisiones tempranas, a veces frágiles, sobre la clave de partición.

Cloud Spanner y el bloqueo con la nube

• Spanner es elogiado como tecnología interna “mágica” de Google con garantías sólidas, pero se ve como:
  • Caro.
  • Un bloqueo profundo con GCP, del que muchos desconfían por la supuesta rotación de productos y problemas pasados de retirada/precios.
• Algunos preferirían tecnología inferior que controlan antes que tecnología superior pero atada a un proveedor; otros dicen que la consistencia y la replicación gestionadas de Spanner pueden valer la prima.

Bases de datos por inquilino vs. fragmentación lógica

• Muchos se preguntan por qué no una BD (o esquema) por cliente, evitando transacciones entre inquilinos.
• Ventajas señaladas: modelo mental más simple, aislamiento, copias de seguridad más fáciles, mover inquilinos grandes entre nodos.
• Desventajas señaladas: la migración y los esquemas se vuelven dolorosos con miles de inquilinos; los vecinos ruidosos siguen existiendo si los inquilinos comparten una instancia física; los metadatos y las migraciones de Postgres pueden convertirse en cuellos de botella.
• Algunos equipos informan de gran éxito con miles de esquemas de inquilino; otros informan haber abandonado el enfoque por ser inmanejable.

Opciones existentes de Postgres / NewSQL

• Los comentaristas señalan similitudes con Citus o Vitess y especulan por qué no se usaron:
  • RDS no admite extensiones como Citus.
  • Limitaciones anteriores de Citus (cuellos de botella del coordinador, restricciones en joins).
  • Riesgo y esfuerzo de una migración completa frente a una fragmentación incremental sobre el conocido RDS Postgres.
• Los sistemas NewSQL (CockroachDB, Yugabyte, TiDB) se ven como atractivos para proyectos greenfield, pero:
  • Introducen nuevas curvas de aprendizaje operativas.
  • Pueden tener peor latencia/throughput para algunas cargas de trabajo.
  • Aun así requieren migraciones de datos complejas y de alto riesgo a la escala de Figma.

Coste, riesgo y compromisos de ingeniería

• Un cálculo sugiere que el coste de ingeniería de la fragmentación interna podría ser de varios millones de dólares y tardar años en “amortizarse” frente a soluciones distribuidas gestionadas.
• Otros responden que, para un producto de alto valor y crecimiento rápido, minimizar el riesgo de migración y aprovechar la experiencia existente en Postgres/RDS pesa más que la optimización pura del coste.

Otros temas

• En general, se considera que NoSQL encaja mal con el modelo altamente relacional de Figma.
• Algunos ven la solución como ingeniosa pero demasiado elaborada y se preocupan por el mantenimiento a largo plazo y el riesgo de “persona clave”.
• Se menciona Aurora Limitless, pero se considera demasiado nuevo y probablemente muy caro.