ADR: Sharding no Aurora: App-Level vs Aurora Limitless vs Citus

Antes de qualquer conversa sobre sharding, é obrigatório esgotar as alternativas verticais e de leitura. Neste cenário, já fizemos isso: o writer está em db.r7g.16xlarge, os read replicas absorvem 100% das queries de leitura via PgBouncer com pool de sessão, e os índices foram revisados por um DBA sênior. O problema é estrutural, o volume de writes não cabe em um único nó, e Aurora não oferece write scaling horizontal nativo no modelo clássico.

O diagnóstico importa aqui. O gargalo não é I/O de storage: Aurora desacopla storage de compute e o distributed storage layer escala automaticamente. O gargalo é o processo de WAL writer e o lock manager no nó de compute. Cada transação commited precisa passar pelo writer, serializar o WAL e aguardar o ACK do quorum de storage nodes. Com 50k TPS de pico e transações médias de 5-8 statements, estamos falando de centenas de milhares de operações de lock/segundo. Isso é um limite de compute, não de storage.

A segunda dimensão do problema é o crescimento. Com 15% de crescimento mensal, mesmo que um upgrade vertical comprasse 6 meses, estaríamos de volta ao mesmo ponto em menos de um ano, e com uma instância ainda maior, mais cara, e com menos opções de escape. Sharding não é apenas sobre o presente; é sobre criar uma arquitetura que escale com o negócio sem exigir uma nova decisão de plataforma a cada ciclo de crescimento.

A terceira dimensão é o time. Seis engenheiros de dados com SLA de 99.99% significa que cada hora de oncall não planejado é cara. A escolha de sharding não pode criar uma superfície operacional que o time não consiga sustentar. Isso elimina imediatamente qualquer solução que exija que o time implemente seu próprio rebalanceamento, gerenciamento de metadados de shard, ou roteamento de queries cross-shard do zero.

Qualquer decisão de sharding envolve tensões que não se resolvem, só se gerenciam. Vou ser explícito sobre cada uma delas:

Shard key e distribuição de dados. Temos tenant_id como chave natural. Isso é uma vantagem enorme: a maioria das queries é scoped por tenant, o que significa que queries cross-shard são exceção, não regra. Mas tenants não são uniformes, alguns têm 100x mais dados que outros. Qualquer estratégia de sharding precisa lidar com hot shards de tenants grandes, seja via sub-sharding, seja via roteamento especial.

Queries cross-shard. Mesmo com 80% das queries scoped por tenant, os 20% restantes existem: relatórios agregados, queries de admin, joins entre tenants em features específicas. A pergunta não é se cross-shard queries acontecerão, mas qual é o custo de executá-las e quem paga esse custo, a aplicação, o banco, ou o engenheiro que precisa reescrever a query.

Rebalanceamento. Shards não são estáticos. Tenants crescem, novos tenants chegam, tenants saem. A capacidade de mover dados entre shards sem downtime é crítica. Soluções que exigem que o time implemente isso manualmente são um risco operacional sério para um time de 6 pessoas.

Compatibilidade com PostgreSQL. O sistema usa features específicas do PostgreSQL: JSONB, pg_trgm para full-text search parcial, e algumas stored procedures legadas. Qualquer solução precisa preservar essa compatibilidade ou o custo de migração de aplicação explode.

Custo. Aurora Limitless tem um modelo de pricing diferente do Aurora clássico, você paga por Distributed Processing Units (DPUs) além do storage. Para workloads que poderiam ser servidos por 2-3 writers independentes com sharding na aplicação, o custo do Limitless pode ser 30-50% maior (estimativa baseada em benchmarks públicos da AWS, não em medição direta neste cenário). Esse delta precisa ser justificado por redução de complexidade operacional.

Vendor lock-in. Aurora Limitless é AWS-specific. Citus é open-source mas tem uma versão gerenciada na Azure (Cosmos DB for PostgreSQL). App-level sharding com PostgreSQL padrão é o mais portável. Para um sistema com SLA de 99.99% e dependência crítica de negócio, a portabilidade tem valor real, mas não é gratuita.

Figma e Notion são casos bem documentados de sharding na camada de aplicação. Ambos funcionaram, mas ambos têm times de engenharia de dados de dezenas de pessoas, anos de runway para estabilizar a implementação, e a capacidade de absorver os custos de uma migração complexa. O que esses casos ensinam não é que sharding na aplicação é uma boa ideia para todos, é que é uma boa ideia para quem tem os recursos para fazê-lo corretamente.

Para um time de 6 engenheiros com SLA de 99.99%, o custo real do sharding na aplicação não é o código de roteamento inicial. É o que vem depois: o primeiro hot shard que aparece às 2h da manhã e precisa ser rebalanceado manualmente; a migration de schema que precisa ser executada em 8 shards de forma coordenada com rollback testado; a query de relatório que alguém escreveu sem shard key e que agora está fazendo full scan em todos os shards; o bug no shard registry que faz 0.1% das writes irem para o shard errado e só é descoberto 3 dias depois.

Esses não são problemas hipotéticos. São os problemas que aparecem invariavelmente em implementações de sharding manual, e a pergunta é se o time tem capacidade de resolvê-los sem comprometer o SLA. A resposta honesta, para um time de 6 pessoas sem experiência prévia em sharding distribuído, é não.

Isso não significa que sharding na aplicação seja errado. Significa que tem um custo de maturidade organizacional que precisa ser reconhecido. Se o time crescer para 15-20 engenheiros com experiência específica em distributed systems, a equação muda, e a portabilidade do sharding manual se torna um ativo real. Hoje, não é.