Patron de Sharding

Resumen

El Patron de Sharding divide un dataset grande en fragmentos mas pequenos llamados shards y los distribuye entre multiples servidores. En lugar de una unica base de datos monolitica, cada shard gestiona un subconjunto de datos, permitiendo crecimiento horizontal.

Este patron es esencial cuando un servidor unico no puede manejar el volumen de datos, throughput de consultas o conexiones concurrentes.

Cuando Usar

• For alternatives, see Database per Service Pattern.

• Dataset excede la capacidad de almacenamiento de un nodo

• Throughput de consultas excede limites de CPU/IOPS

• Reducir latencia ubicando datos geograficamente mas cerca de usuarios

• Escrituras crean contencion de bloqueos en un solo nodo

Cuando Evitar

• Dataset cabe comodamente en un solo servidor
• Consultas cross-shard frecuentes y complejas
• Complejidad operativa de multiples nodos excede capacidad del equipo
• Consistencia transaccional fuerte cross-shard requerida

Solucion

Python (Sharding por Hash con Redis)

import hashlib
import redis

class ShardManager:
    def __init__(self, shards):
        self.shards = shards
        self.num_shards = len(shards)

    def _get_shard_index(self, key):
        return int(hashlib.md5(key.encode()).hexdigest(), 16) % self.num_shards

    def get(self, key):
        return self.shards[self._get_shard_index(key)].get(key)

    def set(self, key, value):
        return self.shards[self._get_shard_index(key)].set(key, value)

shards = [redis.Redis(host=f'redis-{i}', port=6379) for i in range(1, 4)]
manager = ShardManager(shards)
manager.set('user:1001', json.dumps({'name': 'Alice'}))

Java (Sharding por Rango con Spring)

@Component
public class RangeShardRouter {
    private final List<DataSource> shards;
    private final List<Long> boundaries;

    public JdbcTemplate getShardForId(Long id) {
        int index = 0;
        for (Long b : boundaries) { if (id <= b) break; index++; }
        return new JdbcTemplate(shards.get(index));
    }
}

JavaScript (Sharding por Directorio)

class DirectoryShardManager {
    constructor() {
        this.directory = new Map();
        this.shards = new Map();
    }
    registerShard(id, connection) { this.shards.set(id, connection); }
    assignToShard(entityId, shardId) { this.directory.set(entityId, shardId); }
    getShardForEntity(entityId) {
        return this.shards.get(this.directory.get(entityId));
    }
}

Explicacion

Sharding aplica una funcion de shard que mapea cada clave a un shard especifico:

• Por hash: shard = hash(key) % N — distribucion uniforme pero consultas por rango costosas.
• Por rango: Rangos contiguos de claves por shard — eficiente para consultas por rango pero puede crear hotspots.
• Por directorio: Tabla de busqueda explicita — flexible pero agrega complejidad.

Variantes

Variante	Estrategia	Ideal Para
Por hash	hash(key) % N	Distribucion uniforme
Por rango	Limites de rango de clave	Consultas por rango, series temporales
Por directorio	Tabla de busqueda	Sharding geografico, reasignacion flexible
Hash consistente	Mapeo en anillo	Minimizar rebalancing al cambiar shards
Por entidad	Una entidad por shard	SaaS multi-tenant con aislamiento

Lo que Funciona

• Elegir la clave de shard correcta
• Monitorear balance de shards
• Planificar para rebalancing
• Evitar transacciones cross-shard
• Replicar shards para disponibilidad

Errores Comunes

• Mala eleccion de clave de shard
• Ignorar consultas cross-shard
• Sin estrategia de rebalancing
• Asumir crecimiento lineal
• Olvidar joins entre tablas sharded

Ejemplos del Mundo Real

• MongoDB: Usa shard key para distribuir documentos. El balanceador migra chunks entre shards.
• Instagram: Shards PostgreSQL por user ID. Datos de cada usuario viven en un solo shard.
• Discord: Shards mensajes por server ID. Historial de mensajes es local al shard.

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de database-sharding y pattern para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica patron de sharding cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Temas Avanzados

Escenario: Sharding de Base de Datos para E-commerce

Sistema: E-commerce, 50M usuarios, 2TB de datos
Objetivo: Sharding horizontal para escalar writes

Estrategia de sharding:
  | Estrategia | Formula | Ventajas | Desventajas |
  |------------|---------|----------|-------------|
  | Range-based | user_id % 4 = shard | Simple | Hotspots |
  | Hash-based | hash(user_id) % 4 | Distribucion uniforme | Re-sharding complejo |
  | Directory | lookup table -> shard | Flexible | Lookup es bottleneck |
  | Geo-based | region -> shard | Latencia baja | Desbalanceo |

Configuracion (PostgreSQL + pg_partman):
  | Shard | Region | Usuarios | Tamano |
  |-------|--------|----------|---------|
  | shard-0 | US-East | 15M | 600GB |
  | shard-1 | US-West | 12M | 480GB |
  | shard-2 | EU | 13M | 520GB |
  | shard-3 | Asia | 10M | 400GB |

Routing de queries:
  Application -> Shard Router (pgcat / Vitess / Citus)
    -> Determina shard por user_id
    -> Forward query al shard correcto
    -> Agregar resultados si cross-shard

Cross-shard queries (evitar o optimizar):
  | Query | Estrategia |
  |-------|------------|
  | SELECT por user_id | Directo al shard (OK) |
  | SELECT all users | Scatter-gather (lento) |
  | COUNT total | Mantener contador en tabla separada |
  | JOIN cross-shard | Denormalizar o usar cache |
  | ORDER BY global | Mantener top-N en Redis |

Re-sharding (cuando un shard crece demasiado):
  1. Crear nuevo shard (shard-4)
  2. Migrar 50% de datos del shard mas grande
  3. Actualizar shard router
  4. Verificar consistencia
  5. Eliminar datos migrados del shard original
  Duration: 2-4 horas con downtime cero (dual-write)

Lecciones:
  - Sharding es ultima opcion: intenta read replicas y caching primero
  - Hash-based sharding distribuye uniformemente
  - Cross-shard queries son el mayor desafio
  - Re-sharding es complejo: planifica desde el dia 1
  - Directory-based sharding da flexibilidad pero anade latencia

Como manejo transacciones cross-shard?

Evita transacciones cross-shard: disena para que cada transaccion toque un solo shard. Si es inevitable, usa el patron saga: divide la transaccion en pasos locales por shard, con compensacion en caso de fallo. Alternativamente, usa 2PC (two-phase commit) pero tiene overhead. Para la mayoria de casos, re-disena para que la transaccion sea local a un shard.

End of document. Review and update quarterly.

Troubleshooting

• Pattern does not fit the problem: re-evaluate the forces (performance, scalability, team size, coupling). A pattern is only appropriate when its trade-offs match your constraints.
• Too many abstractions: if adding a pattern increases complexity without a clear benefit, simplify. Not every module needs a factory, decorator, or strategy.
• Tight coupling after refactoring: check that interfaces are stable and dependencies point inward.
• Tests break when the design changes: favor stable contracts over internal structure.
• Performance regression from indirection: measure before and after. Layers, decorators, and adapters can add latency; cache or inline hot paths if needed.

Errores Comunes en Producción

• Aplicar el patrón donde no se necesita abstracción, agregando complejidad accidental.
• Dejar que el patrón se filtre en módulos no relacionados y confundir los límites de responsabilidad.
• Sobre-ingeniería en la primera implementación en lugar de comenzar simple y medir el dolor.
• Saltar los tests de contrato, de modo que las refactorizaciones rompan consumidores en silencio.
• Ignorar modos de fallo que el patrón no cubre.
• Usar el patrón como opción por defecto en lugar de elegir la herramienta adecuada para la escala actual.
• Olvidar documentar cuándo dejar de usar el patrón y qué lo reemplaza.
• Carecer de observabilidad sobre rendimiento y propagación de errores del patrón.