Figma: Sharding Horizontal de Postgres Sem Parar de Crescer

O Figma cresceu rápido demais para a sua própria infraestrutura de dados. Durante anos, a arquitetura de banco de dados seguiu o padrão clássico de startups bem-sucedidas: um Postgres primário com réplicas de leitura, escalando verticalmente sempre que os sinais de alerta apareciam. Essa abordagem funcionou — até o momento em que deixou de funcionar.

O problema não foi um único evento catastrófico. Foi uma convergência de pressões: a instância primária acumulando CPU elevada de forma crônica, o WAL (Write-Ahead Log) apresentando lag crescente nas réplicas, e o pool de conexões operando perto do limite físico do PgBouncer. Em sistemas transacionais de alta frequência como o Figma — onde múltiplos usuários editam o mesmo documento em tempo real — qualquer degradação no banco de dados primário se propaga diretamente para a experiência do usuário.

A escala vertical havia chegado ao seu teto prático. Mover para uma instância maior resolveria o problema por meses, não por anos. O time precisava de uma solução estrutural, e a única saída era o sharding horizontal — distribuir os dados entre múltiplos nós Postgres independentes, cada um responsável por um subconjunto das entidades do sistema.

O que torna esse problema especialmente difícil é que o Figma não tinha o luxo de pausar o produto para fazer a migração. O crescimento do negócio continuava, novos usuários chegavam, novos arquivos eram criados. A migração precisava acontecer debaixo de um sistema em plena operação, sem que os usuários percebessem.

A solução do Figma pode ser decomposta em três camadas interdependentes: particionamento lógico, roteamento dinâmico e migração incremental com dupla escrita.

Particionamento lógico por chave de entidade

O esquema de sharding escolhido foi baseado em chave — especificamente, no identificador da entidade raiz (tipicamente o file_id ou equivalente de tenant). Isso significa que todos os dados relacionados a um determinado arquivo ou usuário são colocalizados no mesmo shard físico. A colocação é crítica: queries que atravessam shards (cross-shard joins) são extremamente custosas e, se mal planejadas, eliminam qualquer ganho de escala. O Figma optou por uma abordagem de colocação agressiva para evitar esse antipadrão.

O número de shards lógicos foi definido como um múltiplo intencional dos shards físicos. Isso é uma decisão de engenharia sofisticada: ao separar shards lógicos de shards físicos, o sistema pode rebalancear dados movendo shards lógicos entre nós físicos sem precisar rehashear todas as chaves. É o mesmo princípio do consistent hashing, mas implementado de forma mais explícita com um mapa de shards controlado pela aplicação.

Roteamento dinâmico na camada de aplicação

Em vez de adotar um proxy de banco de dados externo (como Vitess ou Citus), o Figma implementou o roteamento dentro da própria aplicação Rails. Existe um componente central — o shard map — que mantém o mapeamento de shard_id lógico → instância Postgres física. Antes de qualquer query, a aplicação consulta esse mapa para determinar para qual conexão de banco de dados rotear a operação.

Essa escolha tem implicações profundas. Por um lado, elimina um hop de rede e uma camada de infraestrutura adicional para operar. Por outro, acopla a lógica de roteamento ao código da aplicação, o que significa que toda mudança no mapa de shards precisa ser coordenada com o deploy da aplicação — ou gerenciada via feature flags e configuração dinâmica.

Migração incremental com dupla escrita e verificação

A parte mais delicada de toda a operação foi a migração dos dados existentes sem downtime. O processo seguiu um padrão clássico de migração online: primeiro, ativar a dupla escrita (dual-write) para as entidades sendo migradas, onde cada escrita vai tanto para o shard de origem quanto para o shard de destino; segundo, executar o backfill dos dados históricos em background, com controle de taxa para não sobrecarregar o primário; terceiro, verificar a consistência entre origem e destino antes de cortar o tráfego de leitura; quarto, promover o shard de destino como autoritativo e remover a escrita duplicada.

Cada fase dessa migração foi executada de forma incremental, tabela por tabela, entidade por entidade. Não foi uma big-bang migration — foi uma série de migrações cirúrgicas, cada uma com rollback definido.

Qualquer diagrama de sharding parece razoável no papel. A brutalidade está nos detalhes operacionais que o diagrama não captura.

O problema das transações distribuídas

O Postgres não tem suporte nativo a transações distribuídas entre instâncias independentes. Isso significa que qualquer operação que precise de atomicidade entre dois shards diferentes precisa ser redesenhada. O Figma resolveu isso de duas formas: primeiro, através da colocação agressiva de entidades relacionadas no mesmo shard (evitando o problema na origem); segundo, aceitando consistência eventual em casos onde a atomicidade cross-shard era inviável e redesenhando o modelo de dados para eliminar dependências entre shards sempre que possível.

Essa é uma decisão de design que tem impacto direto no produto. Alguns padrões de query que eram triviais no monolito — um JOIN entre tabelas de entidades diferentes — se tornam operações proibidas ou muito custosas no mundo shardado. O time de engenharia precisou auditar todas as queries existentes e classificá-las por padrão de acesso antes de definir a estratégia de particionamento.

O custo humano da dupla escrita

A fase de dual-write é conceitualmente simples, mas operacionalmente cara. Durante o período de migração, cada escrita relevante precisa ir para dois destinos. Isso aumenta a latência de escrita, dobra a pressão sobre o pool de conexões, e introduz um novo vetor de falha: o que acontece se a escrita no shard de destino falhar? O Figma precisou definir políticas explícitas de tratamento de falha para cada fase da migração — e essas políticas precisavam ser conservadoras o suficiente para não corromper dados, mas agressivas o suficiente para não travar o produto.

Gerenciamento do shard map como infraestrutura crítica

O shard map não é um arquivo de configuração estático. É um componente de infraestrutura que precisa ser lido em alta frequência (toda query passa por ele), ter baixíssima latência, e ser atualizado de forma atômica durante rebalanceamentos. O Figma precisou tratar o shard map como um serviço de primeira classe — com cache na aplicação, invalidação controlada e monitoramento dedicado. Uma falha no shard map é uma falha global: se a aplicação não consegue resolver para qual shard rotear uma query, ela não consegue servir nenhuma requisição.

Schema migrations em um mundo shardado

No monolito, uma migration de schema é um evento único e controlado. Com N shards físicos, cada migration precisa ser executada N vezes, de forma coordenada, sem causar inconsistência entre shards durante o período de transição. O Figma adotou a prática de migrations compatíveis com versões anteriores (backward-compatible schema changes) — adicionando colunas como nullable antes de torná-las obrigatórias, mantendo colunas antigas durante períodos de transição — para garantir que diferentes shards pudessem estar em estados de schema ligeiramente diferentes durante o rollout.