Como a equipe de bancos de dados da Figma viveu para contar a escala

DB distribuído vs. Postgres particionado

• Muitos argumentam que esta é a história clássica: começar com uma única instância RDS, atingir os limites de escala, passar anos fazendo sharding; alguns dizem “é só usar um banco de dados distribuído” desde o primeiro dia.
• Outros contrapõem que, em 2012–2016, as opções maduras de SQL distribuído eram limitadas, especialmente para workloads altamente relacionais com muitas junções.
• Vários observam que não existe almoço grátis: sistemas distribuídos acrescentam complexidade, custo e exigem decisões precoces, às vezes frágeis, sobre a chave de partição.

Cloud Spanner e aprisionamento à nuvem

• O Spanner é elogiado como tecnologia interna “mágica” do Google, com fortes garantias, mas visto como:
  • Caro.
  • Um aprisionamento profundo ao GCP, em que muitos não confiam por causa da percepção de rotatividade de produtos e de problemas passados de descontinuação/preços.
• Alguns prefeririam tecnologia inferior sob seu controle a tecnologia superior, mas presa a um fornecedor; outros dizem que a consistência/replicação gerenciadas do Spanner podem valer o prêmio.

Bancos de dados por locatário vs sharding lógico

• Muitos se perguntam por que não um banco de dados (ou schema) por cliente, evitando transações entre locatários.
• Prós relatados: modelo mental mais simples, isolamento, backups mais fáceis, movimentação de grandes locatários entre nós.
• Contras relatados: migração/schemas viram um problema em milhares de locatários; vizinhos barulhentos ainda existem se os locatários compartilham uma instância física; metadados do Postgres e migrações podem se tornar gargalos.
• Algumas equipes relatam grande sucesso com milhares de schemas por locatário; outras relatam ter abandonado a abordagem por se tornar inadministrável.

Opções existentes de Postgres / NewSQL

• Comentadores observam semelhanças com Citus ou Vitess e especulam por que eles não foram usados:
  • O RDS não suporta extensões como Citus.
  • Limitações anteriores do Citus (gargalos no coordinator, restrições de junção).
  • Risco e esforço de uma migração completa versus sharding incremental em um Postgres RDS conhecido.
• Sistemas NewSQL (CockroachDB, Yugabyte, TiDB) são vistos como atraentes para greenfield, mas:
  • Introduzem novas curvas de aprendizado operacional.
  • Podem ter latência/throughput piores para بعض workloads.
  • Ainda exigem migrações de dados complexas e de alto risco na escala da Figma.

Custos, risco e trade-offs de engenharia

• Um cálculo sugere que o custo de engenharia do sharding interno poderia ser de vários milhões de dólares e levar anos para “se pagar” em comparação com soluções distribuídas gerenciadas.
• Outros respondem que, para um produto de alto valor e crescimento rápido, minimizar o risco de migração e aproveitar a experiência existente com Postgres/RDS pesa mais do que a otimização pura de custo.

Outros temas

• NoSQL é geralmente visto como um mau encaixe para o modelo altamente relacional da Figma.
• Alguns veem a solução como engenhosa, mas excessivamente complexa, e se preocupam com a manutenção de longo prazo e o risco de “pessoa-chave”.
• Aurora Limitless é mencionado, mas visto como novo demais e provavelmente muito caro.