Escalabilidade está cheia de regras populares ("é só
adicionar máquina", "Kubernetes resolve") que mais
atrapalham do que ajudam. Cada decisão abaixo é
confronto direto com uma dessas regras — e a resposta
saudável quase sempre depende do tipo de carga e da
topologia do sistema.
Vertical ou horizontal?
Para serviços de aplicação stateless (web, API),
horizontal sempre. Custo linear, capacidade
ilimitada na prática, falha de uma instância
não derruba o sistema. Para banco e cache,
vertical primeiro até o limite — uma máquina
grande é mais simples de operar que cluster
distribuído, e a complexidade de sharding é
cara. AWS RDS suporta instâncias com 96 cores e
terabytes de RAM em 2026; PostgreSQL nessa
máquina aguenta carga que muitos times não
atingem. A regra prática: scale up até começar a
doer, depois scale out.
Sharding agora ou depois?
Quase sempre depois. Sharding é decisão de
design irreversível ou cara de reverter — uma
vez que dados estão particionados por
tenant_id, queries cross-tenant
ficam complicadas; uma vez por user_id,
relatórios agregados ficam pesados. Adiar até
que vertical + replicação não bastem é
geralmente saudável. Quando chegar a hora,
preferir consistent hashing a id mod N;
preferir tenant-based a hash-based em
multi-tenancy; sempre prever resharding desde
o início (mesmo que ainda não tenha sido
necessário).
Multi-region desde o início?
Raramente. Multi-region adiciona complexidade
qualitativa — replicação cross-region, write
locality, latência aumentada, eventual
consistency, custo maior. Para a maioria dos
sistemas que servem um país, single-region
com múltiplas AZs é suficiente para SLA de
99.99%. Multi-region só vale quando: usuários
geograficamente distribuídos com SLO agressivo
de latência (< 100 ms global); requisito
regulatório de soberania de dados; SLA de
99.999% com redundância regional. Para sistemas
que crescem rápido, deixar multi-region como
"v2" é frequentemente decisão correta.
Auto-scaling reativo ou preditivo?
Reativo (baseado em métrica corrente) é o default
saudável para a maioria dos sistemas. Simples,
confiável, ajusta a tráfego real. Limitação: tem
atraso (alguns minutos para scale up). Sistemas
com picos previsíveis e abruptos (Black Friday,
lançamento de produto, Olimpíadas) ganham com
preditivo — escalonar baseado em previsão antes
do pico chegar. AWS Auto Scaling tem Predictive
Scaling; Kubernetes KEDA tem cron-based.
Combinar os dois (preditivo para picos
previsíveis, reativo para o resto) é o padrão
maduro.
CQRS desde o início ou só quando precisar?
Só quando precisar. CQRS adiciona complexidade
qualitativa: dois modelos, sincronização
eventual, projeções para manter. Em sistemas
jovens, complica desproporcionalmente. CQRS
ganha tração quando: read scale >> write
scale (típico em e-commerce, mídia); modelos de
leitura naturalmente diferentes do modelo de
escrita; necessidade de múltiplas projeções
(busca, analytics, dashboard). Mesmo então,
começar com CQRS "leve" (read replica + queries
distintas) antes de adotar event sourcing
completo é caminho mais sustentável.