Replicación y sharding

📐 Fundamento

Topologías de replicación:

Primary-Replica (antes: Master-Slave)

Cliente ──escrituras──→ [Primary]
                           │
                    WAL stream
                           │
              ┌────────────┴────────────┐
              ↓                         ↓
          [Replica 1]              [Replica 2]
          (solo lectura)           (solo lectura)

• El Primary acepta escrituras y lecturas.
• Las réplicas aceptan solo lecturas (útil para distribuir la carga de queries de reporte).
• Si el Primary falla, se promueve una réplica a Primary (failover).

Replicación síncrona vs asíncrona:

Configurar replicación síncrona en PostgreSQL:

-- En postgresql.conf del Primary:
synchronous_commit = on
synchronous_standby_names = 'replica1'

-- En recovery.conf de la Replica:
primary_conninfo = 'host=primary user=replicator'

Problema: replication lag

En replicación asíncrona, la réplica puede estar unos segundos (o más) atrás del primary. Si una aplicación escribe en el primary y luego lee de la réplica, puede no ver el dato que acaba de escribir.

# Problema de replication lag:
db_primary.execute("INSERT INTO pedidos ...")  # escribe en primary
pedido = db_replica.execute("SELECT * FROM pedidos WHERE id = ?")  
# puede devolver None si la réplica aún no tiene el dato

Solución: Leer del primary inmediatamente después de una escritura (o usar replicación síncrona para datos críticos).

📐 Fundamento

El teorema CAP (Eric Brewer, 2000):

Un sistema distribuido puede garantizar como máximo dos de las tres propiedades:

La trampa: La tolerancia a particiones no es opcional en sistemas distribuidos reales. Las redes fallan. Entonces la elección real es: CP o AP.

                    CAP
                   /   \
                  /     \
                CP       AP
               / \       / \
              /   \     /   \
           HBase  Zookeeper  Cassandra
           MongoDB(default) CouchDB

CP (Consistencia + Tolerancia a particiones):

• Si hay una partición de red, el sistema rechaza escrituras hasta recuperar la consistencia.
• Ej: PostgreSQL con replicación síncrona, HBase.

AP (Disponibilidad + Tolerancia a particiones):

• Si hay una partición de red, el sistema sigue respondiendo con datos potencialmente desactualizados.
• Ej: Cassandra, DynamoDB, CouchDB.

¿Qué elige La Esquina?

• Para pedidos y pagos: CP — es mejor rechazar un pedido temporalmente que cobrar dos veces.
• Para el catálogo de platillos: AP — si la réplica muestra el precio de ayer, no es el fin del mundo.

📐 Fundamento

Estrategias de sharding:

1. Range sharding (por rango):

Shard 1: pedidos donde id BETWEEN 1 AND 1,000,000
Shard 2: pedidos donde id BETWEEN 1,000,001 AND 2,000,000
Shard 3: pedidos donde id > 2,000,001

• Ventaja: simple, consultas por rango eficientes.
• Desventaja: hot spots — si todos los nuevos pedidos van al shard 3, ese shard recibe toda la carga.

2. Hash sharding:

shard_id = hash(pedido_id) % num_shards
# pedido_id = 12345 → hash = 9876543 → 9876543 % 3 = 0 → Shard 0

• Ventaja: distribución uniforme de carga.
• Desventaja: consultas por rango requieren consultar todos los shards.

3. Directory-based sharding:

Un servidor de metadatos (lookup service) mantiene un mapa de "qué shard tiene qué datos".

Lookup: pedido_12345 → Shard 2
Lookup: pedido_99999 → Shard 0

• Ventaja: más flexible, permite mover shards.
• Desventaja: el lookup service es un single point of failure.

Problemas del sharding:

Consistent hashing:

En lugar de hash(key) % N (que requiere redistribuir todos los datos si N cambia), consistent hashing organiza los shards en un "anillo". Al agregar o quitar un shard, solo se mueven los datos del shard adyacente — no todos.

Anillo de hash (valores 0-360):
Shard A: 0-120
Shard B: 120-240
Shard C: 240-360

Al agregar Shard D en posición 180:
Shard A: 0-120    (sin cambio)
Shard B: 120-180  (reducido)
Shard D: 180-240  (recibe datos de B)
Shard C: 240-360  (sin cambio)

Solo se mueven los datos entre 180 y 240.