Come funziona la replicazione e quali sono le sue strategie?

Question

Accepted Answer

**La replicazione** mantiene copie dei dati su più server — per **disponibilità** (sopravvivere ai guasti), **scalabilità in lettura** (servire letture da copie), e **distribuzione geografica**. Diverse strategie (primary-replica, multi-primary, sincrone vs asincrone) comportano compromessi.

## Perché è importante

```text
✓ AVAILABILITY/redundancy → if one copy fails, others have the data (no data loss, failover)
✓ READ SCALING → serve reads from replicas (offload the primary) → handle more reads
✓ GEO-DISTRIBUTION → copies near users (lower latency); disaster recovery
→ replication is fundamental to reliable, scalable data systems.
```

## Strategie di replicazione

```text
PRIMARY-REPLICA (master-slave) → one PRIMARY handles writes, replicates to READ replicas:
  ✓ simple; great for read-heavy workloads; the common model
  ✗ the primary is a write bottleneck / single point for writes (failover needed)
MULTI-PRIMARY (multi-master) → multiple nodes accept writes:
  ✓ write availability/scaling, geo-writes  ✗ CONFLICT resolution (concurrent writes to
    the same data) → complex
```

## Sincrono vs asincrono

```text
SYNCHRONOUS → wait for replicas to confirm before acknowledging the write:
  ✓ replicas are consistent (no data loss on failover)  ✗ slower (waits); availability impact
ASYNCHRONOUS → acknowledge the write immediately; replicate in the background:
  ✓ fast writes, high availability  ✗ REPLICATION LAG → replicas briefly behind (stale reads;
    possible data loss if the primary fails before replicating) — eventual consistency
→ trade-off: durability/consistency vs performance/availability
```

## Perché è importante

Comprendere la replicazione è prezioso perché è una **tecnica fondamentale per la disponibilità e la scalabilità in lettura** nei sistemi dati, quindi è una conoscenza importante di system design.

La replicazione — mantenere copie dei dati su più server — serve scopi cruciali: **disponibilità** (sopravvivere ai guasti attraverso ridondanza e failover), **scalabilità in lettura** (servire letture da repliche per alleviare il primary, prezioso per carichi di lavoro read-heavy), e **distribuzione geografica** (copie vicino agli utenti per latenza inferiore, più disaster recovery).

Comprendere questi scopi chiarisce perché la replicazione è fondamentale per sistemi dati affidabili e scalabili.

Comprendere le **strategie** — **primary-replica** (un primary per le scritture che si replicano a repliche di lettura — il modello comune e semplice ottimo per carichi di lavoro read-heavy, anche se il primary è un collo di bottiglia per le scritture) versus **multi-primary** (più nodi che accettano scritture, abilitando scalabilità in scrittura e geo-scritture ma richiedendo complessa risoluzione dei conflitti) — è necessario per scegliere l'approccio giusto.

Comprendere il compromesso **sincrono vs asincrono** è particolarmente importante: la replicazione **sincrona** (aspettare che le repliche confermino prima di riconoscere) mantiene le repliche coerenti e evita la perdita di dati ma è più lenta, mentre la replicazione **asincrona** (riconoscere immediatamente, replicare in background) è veloce e altamente disponibile ma ha **replication lag** (repliche brevemente indietro, causando letture non aggiornate e possibile perdita di dati se il primary fallisce prima di replicare — eventual consistency).

Questo compromesso tra durabilità/coerenza e prestazioni/disponibilità è una decisione di design chiave.

Poiché la replicazione è fondamentale per la disponibilità e la scalabilità in lettura nei sistemi dati e le strategie (primary-replica vs multi-primary) e i compromessi sincrono/asincrono influenzano significativamente la coerenza, le prestazioni e la disponibilità, e poiché comprenderli è importante per progettare sistemi dati, comprendere la replicazione è una conoscenza preziosa e praticamente rilevante di system design — una tecnica fondamentale per la disponibilità e la scalabilità in lettura, con importanti compromessi di strategia e sincrono/asincrono, e centrale per progettare sistemi dati affidabili e scalabili che sopravvivono ai guasti e gestiscono il carico di lettura.