Database em Escala: Replicação, Sharding e Estratégias para Alta Carga
Quando o Banco de Dados Vira o Gargalo
À medida que aplicações crescem, o banco de dados passa a ser o gargalo de performance. Sintomas: CPU do DB em 90%, filas de conexão, queries lentas por lock contention, replicação com lag crescente. A abordagem de escalar verticalmente (servidor maior) tem limites físicos e de custo. Escalar horizontalmente com replicação e sharding é a resposta para alta escala, mas requer mudanças arquiteturais que devem ser planejadas antes de se tornarem urgentes.
📊 Database em Produção — 2025
Estratégias de Escala para Bancos Relacionais
Read Replicas: replica escritas do primary para N réplicas; reads distribuídos entre réplicas — funciona para cargas read-heavy (80%+ reads). Connection Pooling (PgBouncer, ProxySQL): pools de conexões reutilizáveis reduzem overhead de autenticação e permitem milhares de clients com dezenas de conexões reais. Caching (Redis): resultados frequentes cacheados em memória eliminam queries repetidas. Sharding: divide dados entre múltiplos servidores por chave (user_id % N) — escalabilidade linear mas complexidade operacional alta.
Read Replicas
Streaming replication envia WAL (Write-Ahead Log) em tempo real para réplicas. Reads balanceados entre réplicas, writes no primary.
PgBouncer
Connection pooler para PostgreSQL: reduz conexões reais de milhares para dezenas. Modo transaction pooling maximiza eficiência.
Índices Estratégicos
EXPLAIN ANALYZE revela slow queries. Índices compostos, parciais e índices em expressões eliminam full table scans.
Sharding com Citus
Citus transforma PostgreSQL em banco distribuído com sharding automático. Ideal para multi-tenancy e analytics em escala.
Particionamento
Particionamento de tabelas por range (data) ou list (região) melhora performance de queries e facilita arquivamento de dados antigos.
Redis como Cache
Cache-aside pattern: app verifica Redis antes do DB. Invalidação por TTL ou event-driven. Reduz carga em 60-80% para reads repetidos.
⚠️ Armadilhas no Scaling de Banco de Dados
ORMs que fazem uma query por registro em uma lista causam centenas de queries. Use eager loading (JOIN) ou DataLoader para batching.
Transações que duram segundos bloqueiam vacuum do PostgreSQL e criam lag de replicação. Monitore pg_stat_activity regularmente.
Sharding antes de esgotar otimizações mais simples (índices, cache, réplicas) adiciona complexidade desnecessária.
Backup sem teste de restauração é uma falsa segurança. Valide point-in-time recovery mensalmente com dados reais.
O melhor banco de dados é o que você consegue operar com excelência — não necessariamente o mais avançado tecnicamente.
— iSecPlus Data Engineering, 2026
NoSQL: Quando Abandonar o Modelo Relacional
Bancos relacionais não são a resposta para tudo. Cassandra e ScyllaDB brilham para time-series e write-heavy workloads com bilhões de linhas. MongoDB é ideal para documentos semi-estruturados com schema variável. Redis para cache e estruturas de dados em memória. Elasticsearch/OpenSearch para busca full-text e análise de logs. A decisão deve ser baseada nos padrões de acesso: se você faz queries complexas com JOINs, SQL é superior. Se você lê e escreve por chave primária em alta frequência, NoSQL ganha. Muitas arquiteturas usam polyglot persistence — cada tipo de dado no banco certo.
