Arquitetura de referência: alta escala / alto tráfego

À medida que o tráfego cresce, há uma ordem certa para proteger o banco: primeiro as alavancas simples e baratas, depois as complexas. Esta árvore percorre passo a passo a ordem escala vertical → read replica → sharding, padrões de cache (cache-aside, write-back), buffer com fila + backpressure, rate limiting, isolamento do banco com bulkheads/circuit breakers e prevenção de hot spots. Princípio central: deixe para o fim as decisões difíceis de reverter, como sharding, e esgote primeiro os ganhos baratos.

Onde está o gargalo: uma única instância saturada, leituras ou gravações intensas, ou tráfego em rajadas?

Para resolver um problema de escalabilidade no lugar certo, identifique primeiro o gargalo. Uma única instância está saturada em CPU/memória, as leituras predominam, as gravações estão atingindo o limite, ou picos repentinos de tráfego estão esmagando o banco? Cada caso aponta para um componente diferente.

• Uma única instância está saturada; ainda não tentei as alavancas simples
• As leituras são muito intensas e estão crescendo
• Picos repentinos de tráfego / carga em rajadas estão esmagando o banco

Em qual etapa de escala você está: vertical, read replicas ou sharding?

A escalabilidade tem uma ordem certa. A escala vertical (hardware mais potente) é o primeiro passo mais simples; depois você distribui as leituras entre réplicas; somente quando um único primário não dá mais conta das gravações você passa para o particionamento horizontal (sharding). Onde você está?

• Ainda não aumentei o hardware / não esgotei o tuning básico
• As gravações cabem em uma instância, mas preciso distribuir a carga de leitura
• Um único primário não dá mais conta da carga de gravação

Como você vai proteger o banco da carga: buffer, limitação ou isolamento?

Escalar nem sempre é aumentar o banco; muitas vezes é proteger o banco da sobrecarga. Você vai suavizar picos repentinos de gravação com uma fila, limitar a taxa de requests recebidos (rate limiting), ou evitar que uma única dependência derrube o sistema inteiro (bulkhead/circuit breaker)?

• Quero suavizar picos repentinos de gravação
• Quero limitar/compartilhar de forma justa a taxa de requests recebidos
• Não quero que uma dependência com falha derrube o sistema inteiro

Recomendação: escala vertical e tuning básico primeiro

O passo mais barato e menos arriscado é a escala vertical: adicionar mais CPU/RAM/discos mais rápidos e corrigir o básico (índices, pooling de conexões, parâmetros de memória). Esgote esses ganhos antes de decisões complexas como sharding.

Recomendação: distribua as leituras com read replicas

As gravações permanecem em um único primário enquanto o tráfego somente leitura é distribuído entre uma ou mais réplicas. É muito mais simples que sharding e resolve a maioria das cargas com muitas leituras; o primário fica apenas para gravações e leituras críticas para a consistência.

Recomendação: sharding (particionamento horizontal) como último recurso

Quando um único primário não dá conta da carga de gravação, você divide os dados por uma chave em várias partes independentes (shards); cada shard assume parte das gravações. É poderoso, mas difícil de reverter; complica as consultas e transações entre shards, por isso fica para o fim.

Recomendação: padrões de cache (cache-aside + write-back)

Com alto tráfego de leitura, você coloca um cache em memória (Redis) à frente do banco e atende a maioria das leituras sem que elas cheguem ao banco. Para gravações de alto volume, o write-back acumula as gravações e as descarrega no banco em lotes, aliviando o primário.

Recomendação: buffer com fila (backpressure)

Para evitar que picos repentinos de gravação atinjam o banco diretamente, você coloca uma fila durável (ex.: Kafka/uma fila de mensagens) no meio e consome as gravações no ritmo que o banco consegue sustentar. A fila absorve o pico; em vez de falhar de forma síncrona, o sistema opera com latência controlada (backpressure).

Recomendação: rate limiting (limitar a taxa de requisições)

Limitando os requests recebidos por origem (rate limiting), você evita tanto abusos quanto que um único cliente consuma todos os recursos. Limitar a carga que chega ao banco mantém o sistema previsível e justo.

Recomendação: bulkhead + circuit breaker (isolamento)

Para evitar que uma dependência (ex.: um banco que está ficando lento ou um serviço externo) derrube o sistema inteiro, você divide os recursos em compartimentos (bulkheads) e corta temporariamente as chamadas para uma dependência que continua falhando (circuit breaker). Assim, uma falha parcial não se espalha para o sistema inteiro.