8. Proyecto: plan de sharding y réplicas para Enlace

Primero, la calculadora que produce el plan, incluyendo la demostración de remapeo de las lecciones 6-7:

# enlace_scaling_plan.py — el plan de escalado de la base de datos de Enlace.
import bisect
import hashlib
import math
from collections import Counter

# ---------- Numeros-ancla de Enlace ----------
TOTAL_TB = 6.0              # ~6 TB a 5 anios (modulo 2)
qps_read = 3_858           # ~4,000 lecturas/s
qps_write = 39             # ~40 escrituras/s
hit_ratio = 0.90           # cache del modulo 4
tb_per_shard = 1.0         # DECISION: presupuesto de datos por shard (comodo)
reads_per_replica = 2_000  # DECISION: lecturas/s que aguanta una replica

# ---------- Paso 1: cuantos shards por los 6 TB ----------
shards_min = math.ceil(TOTAL_TB / tb_per_shard)
SHARDS = 8                                    # DECISION: 8 (potencia de 2, margen)
print(f"Datos: {TOTAL_TB} TB / {tb_per_shard} TB por shard -> minimo {shards_min} shards")
print(f"Elegimos SHARDS = {SHARDS}  (~{TOTAL_TB/SHARDS*1000:.0f} GB por shard, con margen)\n")

# ---------- Paso 2: carga por shard ----------
reads_to_db = qps_read * (1 - hit_ratio)      # la cache absorbe el 90%
reads_per_shard = reads_to_db / SHARDS
writes_per_shard = qps_write / SHARDS
print(f"Lecturas a la BD (tras cache 90%): {reads_to_db:,.0f}/s -> {reads_per_shard:,.1f}/s por shard")
print(f"Escrituras: {qps_write}/s -> {writes_per_shard:.1f}/s por primary de shard\n")

# ---------- Paso 3: replicas por shard ----------
replicas_needed = max(1, math.ceil(reads_per_shard / reads_per_replica))
replicas_prod = max(2, replicas_needed + 1)   # +1 por redundancia (aguantar N-1)
total_nodes = SHARDS * (1 + replicas_prod)    # 1 primary + R replicas por shard
print(f"Replicas por shard: minimo {replicas_needed}, en produccion {replicas_prod} (redundancia)")
print(f"Nodos totales: {SHARDS} x (1 primary + {replicas_prod} replicas) = {total_nodes}\n")

# ---------- Paso 4: crecer sin tormenta (lecciones 6-7) ----------
def make_keys(k):
    alphabet = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
    out = []
    for i in range(k):
        num, s = 100_000_000 + i, ""
        while num:
            s, num = alphabet[num % 62] + s, num // 62
        out.append(s.rjust(7, "0"))
    return out

def ring_point(text):
    return int(hashlib.md5(text.encode()).hexdigest(), 16) % (2 ** 32)

def node_modn(code, n):
    return int(hashlib.md5(code.encode()).hexdigest(), 16) % n

def build_ring(nodes, vnodes=100):
    ring = {}
    for node in nodes:
        for i in range(vnodes):
            ring[ring_point(f"{node}#{i}")] = node
    return ring

def node_ring(code, ring, pts):
    p = ring_point(code)
    idx = bisect.bisect(pts, p)
    if idx == len(pts):
        idx = 0
    return ring[pts[idx]]

K, N = 1_000_000, SHARDS
keys = make_keys(K)

# mod-N: remapeo al pasar de N a N+1
moved_modn = sum(node_modn(k, N) != node_modn(k, N + 1) for k in keys)

# consistent hashing: mismo experimento sobre el anillo
nodes = [f"db-{i}" for i in range(N)]
ring = build_ring(nodes)
pts = sorted(ring)
before = {k: node_ring(k, ring, pts) for k in keys}
for i in range(100):                           # agregamos el shard 9 (db-8)
    ring[ring_point(f"db-{N}#{i}")] = f"db-{N}"
pts = sorted(ring)
moved_ring = sum(node_ring(k, ring, pts) != before[k] for k in keys)

print(f"Agregar el shard {N+1} (de {N} a {N+1}), {K:,} claves:")
print(f"  mod-N            remapea {moved_modn:>9,}  ({100*moved_modn/K:5.1f}%)  ~{moved_modn/K*TOTAL_TB:.2f} TB movidos")
print(f"  consistent hash  remapea {moved_ring:>9,}  ({100*moved_ring/K:5.1f}%)  ~{moved_ring/K*TOTAL_TB:.2f} TB movidos")
print(f"  mejora: {moved_modn/moved_ring:.1f}x menos datos movidos\n")

# reparto parejo entre los 9 shards tras crecer (vnodes hacen su trabajo)
dist = Counter(node_ring(k, ring, pts) for k in keys)
print("Reparto entre los 9 shards (vnodes=100):", [dist[f"db-{i}"] for i in range(N + 1)])

Qué esperar. Corriendo python enlace_scaling_plan.py sale, exactamente:

Datos: 6.0 TB / 1.0 TB por shard -> minimo 6 shards
Elegimos SHARDS = 8  (~750 GB por shard, con margen)

Lecturas a la BD (tras cache 90%): 386/s -> 48.2/s por shard
Escrituras: 39/s -> 4.9/s por primary de shard

Replicas por shard: minimo 1, en produccion 2 (redundancia)
Nodos totales: 8 x (1 primary + 2 replicas) = 24

Agregar el shard 9 (de 8 a 9), 1,000,000 claves:
  mod-N            remapea   888,920  ( 88.9%)  ~5.33 TB movidos
  consistent hash  remapea   130,623  ( 13.1%)  ~0.78 TB movidos
  mejora: 6.8x menos datos movidos

Reparto entre los 9 shards (vnodes=100): [107501, 95552, 117241, 110026, 105966, 111195, 117227, 104669, 130623]

Lee la salida contra los criterios de aceptación:

• 8 shards, ~750 GB cada uno. Con un presupuesto de 1 TB por shard, los 6 TB piden un mínimo de 6; elegimos 8 (potencia de 2, cómoda de razonar) para dejar cada shard en ~750 GB, con holgura para crecer antes del siguiente reshard.
• Carga por nodo diminuta: tras la caché (90%) solo llegan 386 lecturas/s a la base de datos, que repartidas entre 8 shards son ~48/s por shard; las escrituras son ~5/s por primary. La caché (M4) y el sharding juntos dejan a cada nodo casi ocioso —esa holgura es la que absorbe los picos y el día del miss masivo—.
• 2 réplicas por shard. El piso aritmético es 1 réplica por shard (48/s cabe de sobra en el presupuesto de 2,000/s), pero desplegamos 2 para aguantar con una caída (regla N−1, lección 3): si una réplica cae, la otra absorbe su carga sin sudar. Total: 8 × (1 primary + 2 réplicas) = 24 nodos.
• Crecer sin tormenta, medido: agregar el shard 9 con mod-N remapea 888,920 claves (88.9%) ≈ 5.33 TB; con consistent hashing, 130,623 (13.1%) ≈ 0.78 TB —6.8× menos datos movidos—. Esa es la diferencia entre una migración de horas que enfría toda la caché y una operación de rutina que solo toca el arco del nodo nuevo.
• Reparto parejo tras crecer: con vnodes=100, los 9 shards quedan entre ~95k y ~130k claves —razonablemente parejo, sin el desbalance 10× que tendría el anillo sin vnodes (lección 7)—. El shard nuevo db-8 tiene 130,623, que es exactamente el número de claves remapeadas: al agregar un nodo, las únicas claves que se mueven son las que ese nodo captura de su arco (nadie se mueve entre nodos viejos).

El diagrama de la topología

flowchart TD
    client["Clientes"]
    cache["cache (Redis)<br/>hit ratio 90%<br/>absorbe 3,472/s"]
    router["Capa de enrutamiento<br/>shard = ring(short_code)"]

    client -->|"resolve / shorten"| cache
    cache -->|"miss: 386 lec/s + 39 esc/s"| router

    subgraph shard0["Shard 0 (~750 GB)"]
        p0[("PRIMARY<br/>escrituras")]
        r0a[("replica")]
        r0b[("replica")]
        p0 -->|replication log| r0a
        p0 -->|replication log| r0b
    end

    subgraph shardN["Shard 7 (~750 GB)"]
        pN[("PRIMARY<br/>escrituras")]
        rNa[("replica")]
        rNb[("replica")]
        pN -->|replication log| rNa
        pN -->|replication log| rNb
    end

    router -->|"escritura -> primary"| p0
    router -->|"lectura -> replica"| r0a
    router -->|"escritura -> primary"| pN
    router -->|"lectura -> replica"| rNa

    note["... shards 1..6 iguales<br/>(8 shards x 3 nodos = 24)"]

La tabla de capacidad

La lista de tradeoffs

• Por qué 8 shards y no 6 (el mínimo). 6 shards cabrían (1 TB cada uno), pero dejan poco margen antes del siguiente reshard. 8 deja ~750 GB por shard y es potencia de 2. Costo: más nodos que operar. Qué lo cambiaría: si el crecimiento fuera más rápido de lo previsto, arrancaría con más shards; con consistent hashing, agregar el 9º ya no es traumático, así que empezar ajustado es menos arriesgado que antes.
• Por qué 2 réplicas por shard y no 1. El cálculo dice 1, pero 1 no tolera una caída. Costo: duplica los nodos de lectura (de 8 a 16 réplicas). Qué lo cambiaría: si la caché fuera aún más efectiva o el SLA más laxo, 1 réplica + failover al primary podría bastar; para un servicio siempre disponible, la redundancia vale su costo.
• Por qué consistent hashing y no mod-N. mod-N reparte igual de bien con N fijo, pero al crecer remapea el 88.9% (5.33 TB, caché fría total). Consistent hashing mueve ~13.1% (0.78 TB). Costo: algo más de complejidad (el anillo, los vnodes, una tabla de posiciones). Qué lo cambiaría: nada realista; el anillo es la elección estándar. Solo un sistema que nunca cambia N podría quedarse con mod-N, y "nunca crecer" no es un plan.
• Por qué replicación asíncrona (lag) y no síncrona. El dato de Enlace (short_code → long_url) tolera un lag de milisegundos sin drama, y la asíncrona es más rápida. Costo: el problema de "lee tu propia escritura" —un short_code recién creado resuelto desde una réplica atrasada da 404 fugaz—. Mitigación: leer del primary por un instante tras crear (lección 4). Qué lo cambiaría: si Enlace necesitara consistencia fuerte en la lectura inmediata, la síncrona o el read-from-primary permanente, a costa de latencia.

import math
TOTAL_TB, tb_per_shard = 12.0, 1.0
qps_read, hit_ratio, reads_per_replica = 8_000, 0.90, 2_000

shards = math.ceil(TOTAL_TB / tb_per_shard)          # 12 -> redondeamos a 16 (potencia de 2)
SHARDS = 16
reads_to_db = qps_read * (1 - hit_ratio)             # 800/s
per_shard = reads_to_db / SHARDS                      # 50/s
replicas = max(2, math.ceil(per_shard / reads_per_replica) + 1)
print(SHARDS, f"{per_shard:.1f}/s por shard", f"{replicas} replicas",
      SHARDS * (1 + replicas), "nodos")
# 16 50.0/s por shard 2 replicas 48 nodos

• (a) Shards: 12 TB / 1 TB = 12 mínimo; redondeamos a 16 (potencia de 2, margen), ~750 GB por shard como antes.
• (b) Lecturas por shard: la caché deja (1 − 0.90) × 8,000 = 800/s a la base de datos, repartidas entre 16 shards son 50/s por shard —igual de diminuto que antes, porque al duplicar datos y lecturas también duplicamos shards—.
• (c) Réplicas y nodos: 50/s cabe en 1 réplica, pero por redundancia 2 por shard; total 16 × 3 = 48 nodos. La lección: al escalar proporcional (datos y lecturas suben juntos, shards también), la carga por nodo se mantiene constante; el sistema crece "hacia los lados" sin que ningún nodo se caliente. Y gracias a consistent hashing, pasar de 8 a 16 shards se hace en incrementos (9, 10, …16), cada uno moviendo solo ~1/N, no todo de golpe.

• (a) Por shard: 4,000 / 8 = 500 lecturas/s por shard (repartidas por hash). El sharding ya divide el golpe entre 8: sin sharding, un solo nodo recibiría las 4,000.
• (b) Sí aguanta. Cada shard tiene 2 réplicas con presupuesto de 2,000/s cada una = 4,000/s de capacidad de lectura por shard; recibe 500/s. Incluso si una réplica del shard cayera durante el incidente, la otra sola (2,000/s) absorbe los 500/s con muchísimo margen. El diseño N−1 y el sharding juntos hacen que el miss masivo —que sin ellos tumbaría una BD única— sea un no-evento: 500/s por shard es una fracción del presupuesto.
• (c) Mitigaciones del plan: (1) precalentar la caché tras un reinicio antes de exponerla al tráfico, para que el hit ratio no arranque en 0; (2) la holgura de capacidad —cada nodo corre casi ocioso en estado estacionario (~48/s) justo para absorber picos como este—; y (3) el sharding, que reparte el golpe entre 8 nodos en vez de concentrarlo. La caché es la primera línea; réplicas + sharding son la red debajo, dimensionada para sobrevivir el día que la caché falla.

• (a) 24 nodos es desperdicio → no, es por los datos y la redundancia, no por el throughput. Tienes razón en que 40 esc/s y 386 lec/s son cargas triviales; los 24 nodos no salen del throughput sino de dos cosas: (1) los 6 TB no caben en una máquina, y partirlos pide 8 shards; y (2) cada shard necesita réplicas para sobrevivir una caída (redundancia N−1), de ahí las 2 por shard. La capacidad de cómputo sobra —cada nodo corre casi ocioso—; lo que no sobra es espacio (6 TB) ni tolerancia a fallos. Podrías usar 6 shards en vez de 8 para ahorrar, pero no bajar mucho más sin quedarte sin margen de almacenamiento ni de redundancia.
• (b) mod-N en vez de consistent hashing → reparte igual con N fijo, pero al crecer es una tormenta. Cierto que mod-N es una línea y reparte parejo mientras N no cambie. El problema aparece el día que agregas el shard 9: lo medí, remapea el 88.9% (888,920 claves, 5.33 TB) y enfría toda la caché, contra el 13.1% (0.78 TB) de consistent hashing. Como shardear existe para poder crecer, elegir el esquema que hace del crecimiento una catástrofe no tiene sentido. La complejidad extra del anillo se paga una vez; la tormenta de mod-N se paga en cada reshard.
• (c) long_url como clave de shard → no, la lectura dominante no la conoce. La operación que domina es resolve(short_code) → long_url: llega un short_code y hay que encontrar la long_url. Si shardeara por long_url, resolve no sabría a qué shard ir (no tiene la long_url, justamente la está buscando), así que cada resolución preguntaría a todos los shards —una consulta cruzada, lenta, a 386/s—. El short_code es la clave correcta porque la lectura dominante siempre lo trae en la mano, es de altísima cardinalidad (62⁷) y, hasheado, reparte parejo (lección 5).

La lección de este ejercicio: un plan de escalado no es una pila de máquinas, es un conjunto de decisiones —cuántos shards y por qué, cuántas réplicas y por qué, qué esquema de reparto y por qué— que sabes defender con la aritmética y con los experimentos del módulo. Cada objeción se responde reconociendo lo cierto y anclando la decisión en un número medido.