Como você escala bancos de dados?

Question

Accepted Answer

Bancos de dados frequentemente se tornam um **gargalo** conforme os sistemas crescem. Escalá-los envolve técnicas como **replicação** (cópias para escala de leitura e disponibilidade), **sharding** (divisão de dados entre servidores), **caching**, e escolha de tipos de banco de dados apropriados.

## Replicação — cópias dos dados

```text
REPLICATION → maintain COPIES of the database across servers:
  → PRIMARY (writes) + REPLICAS (copies):
    - READ SCALING → direct reads to replicas (offload the primary) → handle more reads
    - AVAILABILITY → a replica can take over if the primary fails (failover)
  ⚠️ replication lag → replicas may be slightly behind (eventual consistency for reads)
→ great for READ-heavy workloads and availability (most apps are read-heavy)
```

## Sharding — divisão dos dados

```text
SHARDING → split (partition) data across MULTIPLE database servers (each holds a SUBSET):
  → distribute by a SHARD KEY (e.g. user ID) → each shard handles part of the data/load
  → scales WRITES and storage horizontally (beyond one server's capacity)
  ⚠️ complex: choosing a good shard key (even distribution), cross-shard queries are hard,
    rebalancing → significant complexity
→ for when data/write volume exceeds a single server (large scale)
```

## Outras técnicas de escala

```text
✓ CACHING → cache query results / hot data (Redis) → big reduction in DB load (often the
  first and most impactful step)
✓ INDEXING & query optimization → make queries efficient (before scaling out)
✓ Read/write SPLITTING; connection pooling; denormalization (for read performance)
✓ Choose the right DATABASE (some scale horizontally more easily — NoSQL)
✓ Vertical scaling (bigger DB server) → simple first step, but limited
```

## Por que isso importa

Compreender como escalar bancos de dados é valioso porque o **banco de dados frequentemente é o gargalo** conforme os sistemas crescem, então escalá-lo é um desafio crítico e comum de design de sistemas, tornando esse conhecimento importante.

Conforme os sistemas escalam, o banco de dados frequentemente se torna o fator limitante (um único banco de dados pode lidar apenas com uma certa quantidade de carga e dados), tornando a escala de banco de dados uma preocupação chave.

Compreender **replicação** — manter cópias (um primário para escritas mais réplicas) para permitir **escala de leitura** (direcionar leituras para réplicas para descarregar o primário, valioso já que a maioria dos aplicativos é pesada em leitura) e **disponibilidade** (uma réplica assumindo no caso de falha) — é uma técnica fundamental e amplamente utilizada, junto com a compreensão da ressalva de lag de replicação (consistência eventual para leituras de réplicas).

Compreender **sharding** — dividir dados entre múltiplos servidores (cada um contendo um subconjunto, distribuído por uma chave de shard) para escalar **escritas e armazenamento** horizontalmente além de um servidor — é essencial para escala muito grande, junto com sua complexidade significativa (escolher uma boa chave de shard, consultas difíceis entre shards, rebalanceamento).

Compreender **outras técnicas** — **caching** (frequentemente o primeiro e mais impactante passo, reduzindo drasticamente a carga do banco de dados), **indexação e otimização de consultas** (tornando consultas eficientes antes de escalar), divisão de leitura/escrita, desnormalização, escolha de bancos de dados escaláveis horizontalmente, e escala vertical como um primeiro passo simples — fornece o kit completo, com a sabedoria prática importante de que caching e otimização frequentemente vêm antes da complexidade do sharding.

Já que o banco de dados é comumente o gargalo de escala e escalá-lo (via replicação para leituras/disponibilidade, sharding para escritas/armazenamento, caching e otimização) é um desafio crítico e comum, e já que compreender essas técnicas e seus trade-offs é importante para projetar sistemas escaláveis, compreender como escalar bancos de dados é conhecimento valioso e praticamente importante de design de sistemas — abordando um gargalo crítico e comum, central para escalar sistemas reais, e exigindo compreensão de replicação, sharding, caching e otimização para lidar com a escala de banco de dados que os sistemas em crescimento inevitavelmente necessitam.