¿Cómo fragmentarías (shard) una base de datos para 1000 millones de usuarios?

Question

IT Interview Practice · Accepted Answer

Fragmenta por una clave que esté **presente en casi todas las queries y reparta la carga de forma uniforme** — normalmente un `user_id` hasheado — y planifica el resharding y las queries cross-shard desde el día uno. 1B de usuarios no caben ni rinden en un solo nodo; divides las filas entre muchas bases de datos y enrutas cada query al shard que la posee.

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← each = its own primary+replicas
Directory/lookup table (which key → which shard) ── for range or resharding
```

## Elección de la shard key — la decisión difícil de deshacer

Elige una clave con **alta cardinalidad, distribución uniforme y presente en la mayoría de las queries**. `user_id` suele ganar: las queries con alcance de usuario ("mi perfil, mis pedidos") golpean exactamente un shard. Una clave mala (p. ej. `country`) crea hotspots — un shard alberga toda la India mientras otro está inactivo.

## Hash vs range

- **Hash sharding** (`shard = hash(user_id) % N`): distribuye uniformemente, mata los hotspots — pero las range queries ("usuarios creados la última semana") deben hacer scatter-gather sobre todos los shards.
- **Range sharding** (`user_id 0–1M → shard 0`): mantiene los rangos locales y facilita el resharding, pero arriesga hotspots (los usuarios más nuevos aterrizan todos en el último shard).
- Respuesta común: **hash para carga uniforme**, con una **tabla lookup/directory** para poder mover rangos sin re-hashear todo.

## Resharding — planifícalo antes de necesitarlo

`% N` es una trampa: añadir un shard remapea casi todas las claves. Usa **consistent hashing** o **virtual buckets** (mapea claves → 4096 buckets lógicos → shards físicos). Dividir un shard entonces mueve buckets, no todo el keyspace. Herramientas como **Vitess** (usada por YouTube/Slack) automatizan el resharding en vivo con cutover.

## Queries cross-shard

Cualquier cosa no indexada por la shard key es dolorosa: una query global de "top posts" hace fan-out a cada shard y hace merge. Mitiga **desnormalizando** o manteniendo un índice/store de búsqueda separado (Elasticsearch) para las lecturas transversales.

## Perspectiva de la entrevista

Los entrevistadores sondean si entiendes que la elección de la shard key es **semi-permanente** y si has pensado en el **resharding y los joins cross-shard** — las dos cosas que muerden en producción. Bueno: "fragmenta por user_id." Excelente: planteas el consistent hashing, la mitigación de hot-shard, y el hecho de que las transacciones distribuidas entre shards se evitan mejor por completo.

**Trampa común:** `hash % N` con un N fijo — convierte el crecimiento futuro en una migración de datos completa.

## Compensaciones y modos de fallo

- **ACID cross-shard perdido:** no hay joins/transacciones baratos entre shards; usa sagas o desnormaliza.
- **Shard caliente:** un usuario viral; sub-fragmenta o cachea esa entidad.
- **Riesgo de rebalanceo:** la migración en vivo debe hacer doble escritura y verificar antes del cutover.
- **Coste operativo:** N shards × réplicas = muchas bases de datos que monitorear, respaldar y hacer failover.

Elección de la shard key — la decisión difícil de deshacer

Hash vs range

Resharding — planifícalo antes de necesitarlo

Queries cross-shard

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas