Come si scalano i database?

Question

Accepted Answer

I database spesso diventano un **collo di bottiglia** man mano che i sistemi crescono. Scalare il database coinvolge tecniche come la **replication** (copie per scalare le letture e la disponibilità), lo **sharding** (dividere i dati tra server), il **caching**, e la scelta di tipi di database appropriati.

## Replication — copie dei dati

```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 — divisione dei dati

```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)
```

## Altre tecniche di scaling

```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
```

## Perché è importante

Capire come scalare i database è prezioso perché il **database è spesso il collo di bottiglia** man mano che i sistemi crescono, quindi scalarlo è una sfida critica e comune nel system design, rendendo questa una conoscenza importante.

Man mano che i sistemi si scalano, il database frequentemente diventa il fattore limitante (un singolo database può gestire solo un certo carico e quantità di dati), rendendo il database scaling una preoccupazione chiave.

Capire la **replication** — mantenere copie (un primary per le scritture più replicas) per abilitare il **read scaling** (indirizzare le letture alle replicas per scaricare il primary, prezioso poiché la maggior parte delle app sono read-heavy) e la **disponibilità** (una replica che prende il controllo in caso di guasto) — è una tecnica fondamentale e ampiamente usata, insieme alla consapevolezza dei limiti della replication lag (eventual consistency per le letture da replica).

Capire lo **sharding** — dividere i dati tra più server (ognuno contenente un sottoinsieme, distribuito da una shard key) per scalare **scritture e storage** orizzontalmente oltre un singolo server — è essenziale per scale molto grandi, insieme alla sua significativa complessità (scegliere una buona shard key, query difficili tra shards, ribilanciamento).

Capire le **altre tecniche** — il **caching** (spesso il primo e più impattante step, riducendo drasticamente il carico del database), l'**indexing e query optimization** (rendere le query efficienti prima di scalare out), read/write splitting, denormalizzazione, scegliere database scalabili orizzontalmente, e lo scaling verticale come primo step semplice — fornisce il toolkit completo, con la saggezza pratica importante che caching e optimization spesso precedono la complessità dello sharding.

Poiché il database è comunemente il collo di bottiglia del scaling e scalarlo (via replication per letture/disponibilità, sharding per scritture/storage, caching, e optimization) è una sfida critica e comune, e poiché comprendere queste tecniche e i loro trade-offs è importante per progettare sistemi scalabili, capire come scalare i database è una conoscenza di system design preziosa e praticamente importante — affrontando un collo di bottiglia critico e comune, centrale per scalare sistemi reali, e richiedendo la comprensione di replication, sharding, caching, e optimization per gestire il database scaling che i sistemi in crescita inevitabilmente necessitano.