Estratégias de escalabilidade de banco de dados: quando permanecer monolítico vs. quando distribuir

Resumo executivo

Escalabilidade de banco de dados é uma das decisões arquiteturais mais caras de reverter. Migrar um banco de dados PostgreSQL monolítico estabelecido para uma arquitetura distribuída com sharding não é um projeto de fim de semana — é um rewrite de modelo de dados, lógica de aplicação e contrato de consistência. Muitas equipes precipitam-se para distribuição por hype de cloud-native, pagando o preço em complexidade operacional sem ganhos reais de performance.

Para arquitetos e tech leads, a decisão estratégica não é "sharding ou não sharding", mas "qual padrão de acesso de dados e requisitos de consistência exigem que grau de distribuição". Um monolito de banco de dados otimizado pode escalar para milhões de requisições/segundo com caching estratégico, replica de leitura e índices inteligentes. Distribuição prematura introduz latência de cross-shard queries, joins impossíveis, eventual consistency e complexidade operacional que devoram time de engenharia sem valor claro para o negócio.

Padrões de escalabilidade: o continuum de decisão

Escalabilidade Vertical (Scale-Up)

O caminho mais simples: alocar mais recursos (CPU, RAM, SSD) na mesma máquina. Um servidor de banco de dados com 128 vCPUs, 1TB RAM e NVMe SSD pode servir trabalho massivo sem mudança arquitetural.

Quando funciona:

• Padrões de acesso são previsíveis e focados em subset de dados ativos
• Dataset cabe em memória hot (working set)
• Operações são predominantemente de leitura (read-heavy)
• Latência de disco é o bottleneck, não CPU

Limites práticos:

• Hardware de alto custo tem diminishing returns (custo marginal por performance aumenta exponencialmente)
• Failover requer máquinas de espera quente caras
• Single point of failure persiste até replicação ser implementada

Otimizações que estendem vida útil de scale-up:

• Connection pooling: Reutilizar conexões existentes em vez de abrir/fechar para cada requisição (PgBouncer, ProxySQL).
• Read replicas: Redirecionar queries de leitura para réplicas, mantendo o master apenas para writes. Isso escala linearmente throughput de leitura.
• Intelligent indexing: Índices compostos que cobrem queries comuns (covering indexes) eliminam table scans.
• Materialized views: Pré-agregar dados computacionalmente pesados e atualizar periodicamente em vez de computar em tempo real.
• Query caching: Camada de cache (Redis, Memcached) para queries de leitura repetitivas.

Escalabilidade Horizontal por Caching

Antes de distribuir o banco de dados, distribuir o cache. Cache read-through e write-through reduzem pressão diretamente no banco de dados principal.

Padrões de cache:

• Read-through: Aplicação busca no cache; se miss, busca no banco e popula cache.
• Write-through: Aplicação escreve no banco e no cache sincronamente.
• Write-behind: Aplicação escreve no cache, assíncrono para banco (melhor performance, risco de data loss).
• Cache invalidation: Invalidar cache entries quando dados mudam ao invés de TTL passivo.

Quando caching resolve:

• Padrões de leitura repetitivos (mesmo data subset lido milhares de vezes)
• Read-heavy workloads (ex: dashboards, feeds de usuário)
• Data pode ser eventualmente consistente por breves períodos
• Dataset de leitura cabe inteiramente em cache hot

Anti-padrão de caching: Cache writes sem estratégia de invalidação consistente. Se você cache user:123 mas invalida apenas por TTL, leituras subsequentes podem retornar dados stale por segundos ou minutos, violando requisitos de consistência. Write-through patterns são mais lentos mas garantem eventual consistency imediata.

Sharding: distribuição por chave

Particionar dataset horizontalmente em shards baseados em uma chave de distribuição (shard key). Cada shard opera independente com seu próprio subset de dados.

Estratégias de shard key:

• Hash-based: hash(customer_id) % num_shards distribui uniformemente. Desvantagem: queries que precisam de range scans são impossíveis (ex: "todos os pedidos entre jan e mar").
• Range-based: Shards por range de data, ID ou outro atributo sequencial. Vantagem: range queries são eficientes. Desvantagem: hotspots naturais (últimos 30 dias sempre no shard 1).
• Directory-based: Serviço de mapeamento central mantém lookup de customer_id → shard_id. Flexível mas adiciona latência de lookup.

Quando sharding vale o custo:

• Dataset não cabe em memória mesmo em hardware de alto custo
• Write throughput excede capacidade de master + replicas
• Padrões de acesso são naturalmente particionáveis por domínio (ex: cada cliente acessa apenas seus dados)
• Você pode tolerar eventual consistency entre shards

Complexidades de sharding:

• Cross-shard queries: Queries que precisam de dados de múltiplos shards requerem aggregation na aplicação, criando latência e complexidade.
• Transactions across shards: ACID transactions entre shards são impossíveis sem two-phase commit distribuído (complexo e lento).
• Rebalancing: Quando um shard cresce além de capacidade, rebalanceamento é operação massiva e perigosa.
• Data migration: Migrar para sharding requer downtime ou complexidade de dual-write.

Sharding by Application Domain

Em vez de shard by ID técnico, shard por bounded context de domínio. Dados de pagamentos em shard próprio, dados de pedidos em outro, dados de usuário em outro.

Quando funciona:

• Domínios têm padrões de acesso e requisitos de consistência distintos
• Compatibilidade entre domínios é limitada (necessita join cross-shard raramente)
• Cada domínio tem própria equipe de desenvolvimento e SLA

Vantagens:

• Independência técnica: cada domínio escolhe tecnologia apropriada (PostgreSQL para relacional, MongoDB para documentos, Redis para cache).
• Isolamento de falha: problema em shard de pagamentos não afeta shard de pedidos.
• Independência de escalabilidade: domínio de analytics pode escalar sem afetar domínio de transações.

Desvantagens:

• Cross-domain joins tornam-se impossíveis sem complexidades de federated queries.
• Duplication de dados inevitável (ex: customer_id em múltiplos domínios).
• Coordenação de schema changes entre domínios exige governança estrita.

Matriz de decisão

A decisão entre permanecer monolítico vs. distribuir depende de quatro dimensões:

1. Padrão de Acesso de Dados

Monolítico funciona quando:

• 80%+ de queries acessam <20% de dados ativos (hot data)
• Queries são predominantemente de leitura
• Join patterns são complexos e frequentes

Distribuição faz sentido quando:

• Acesso é uniformemente distribuído across dataset
• Write-heavy workloads
• Queries são naturalmente scoped por ID (ex: "pedidos do usuário X")

2. Requisitos de Consistência

Strong Consistency (ACID):

• Transações financeiras (pagamentos, transfers)
• Inventário com verificação de disponibilidade real-time
• Sistema de reservas com double-booking não aceitável

→ Permanecer monolítico ou sharding com complexo two-phase commit

Eventual Consistency:

• Analytics, relatórios, dashboards
• Feeds de atividade, timelines
• Catálogos de produtos com baixa criticidade

→ Distribuição é viável com estratégias de eventual consistency

3. Ponto de Crescimento Atual

Pre-sharding: Você pode antecipar growth patterns e projetar sharding desde início (ex: hash de customer_id como shard key primário). Isso reduz custo de re-arquitetura futura mas introduz complexidade prematura.

Post-sharding migration: Migrar monolito estabelecido para sharding é operação multi-fase:

1. Dual-write: Aplicação escreve em monolito e shards
2. Backfill: Migrar dados históricos para shards
3. Cutover: Redirecionar leitura para shards, manter monolito em backup
4. Cleanup: Desligar monolito após período de estabilização

4. Capacidade da Equipe

Operação de sistema distribuído exige:

• Expertise em troubleshooting distribuído (tracing, logging)
• Disciplina de schema evolution (sem breaking changes sem transição)
• Processos de incident response para cross-shard issues
• Observability abrangente (métricas por shard, lag de replicação)

Se a equipe não tem essa maturidade, distribuição prematura cria debt técnico operacional que consome mais tempo de engenharia do que problemas de performance que ela supostamente resolve.

Anti-padrões comuns

Anti-padrão: "One-size-fits-all" Database

Usar o mesmo banco de dados para todos os casos de uso: relacional para dados altamente estruturados, documento para semi-estruturados, chave-valor para cache, time-series para logs. Polyglot persistence permite otimizar cada workload mas multiplica complexidade operacional. Comece com PostgreSQL para tudo; introduza outras tecnologias quando existir evidência clara de benefício.

Anti-padrão: Premature Sharding

Implementar sharding quando dataset cabe em memória de servidor único e throughput é limitado por queries não otimizadas. Sharding é otimização de último recurso, não primeira linha de defesa.

Anti-padrão: Ignoring Caching Strategy

Saltar diretamente para sharding sem explorar read replicas, materialized views, query optimization e connection pooling. Cada camada de otimização é mais simples e barata do que distribuição de dados.

Anti-padrão: Hardcoded Shard Counts

Designar sharding com número fixo de shards sem estratégia de rebalancing. Quando shard 1 cresce mais rápido que shard 5, você fica preso com hotspots operacionais impossíveis de corrigir sem refactoring massivo.

Métricas para decisões de escalabilidade

Para fundamentar decisões de arquitetura de banco de dados, monitore:

• Query Latency P99: Latência de queries de leitura/escrita. Spikes indicam necessidade de otimização.
• Connection Pool Saturation: Taxa de conexões vs. capacidade de pool. Saturation indica necessidade de connection pooling mais eficiente ou scale-up.
• Cache Hit Rate: Porcentagem de queries servidas por cache. Taxas baixas (<70%) indicam padrões de acesso não cache-friendly.
• Database CPU Utilization: Utilização contínua >80% indica necessidade de scale-up ou sharding.
• Storage Growth Rate: Taxa de crescimento de dataset. Se você projetar exaurimento em 6 meses, comece planejamento de sharding agora.
• Cross-shard Query Rate: Em sistemas sharded, taxa de queries que acessam múltiplos shards. Taxas altas indicam shard key inapropriada.

Próximos passos de maturidade

Fase 1: Otimização de Monolito (Meses 1-3)

• Implementar connection pooling inteligente
• Adicionar read replicas para workload read-heavy
• Criar materialized views para queries pesadas
• Implementar caching read-through para dados de leitura repetitiva
• Otimizar índices para cobrir query patterns mais frequentes

Fase 2: Preparação para Distribuição (Meses 3-6)

• Mapear bounded contexts de domínio
• Identificar padrões de acesso por domínio
• Projetar shard keys candidates
• Implementar observability per-domain
• Criar processos de schema evolution e data migration

Fase 3: Implementação Controlada de Sharding (Meses 6-12)

• Começar com domain-based sharding (bounded contexts)
• Implementar dual-write strategy para transição
• Migrar fluxos de menor risco para shards
• Estabelecer SLAs e alertas per-shard
• Documentar processos de rebalancing e incident response

Fase 4: Operação de Sistema Distribuído (Meses 12+)

• Expandir sharding para domains críticos
• Implementar caching cross-shard para eventual consistency
• Criar estratégias de automated failover e disaster recovery
• Estabelecer processos regulares de capacity planning
• Governar polyglot persistence se necessário

Sua arquitetura de banco de dados está escalando de forma ineficiente, criando gargalos que impedem crescimento do negócio? Falar sobre arquitetura de dados com a Imperialis para projetar estratégias de escalabilidade que equilibram performance, consistência e complexidade operacional.

Fontes

• Amazon RDS Scaling Best Practices — accessed on 2026-03
• Google Cloud: Database Scaling Strategies — accessed on 2026-03
• PostgreSQL Documentation: Partitioning — accessed on 2026-03
• Martin Fowler: Database Patterns — accessed on 2026-03
• High Scalability Blog — accessed on 2026-03