Software Architecture
Explica replicación, particionamiento y sharding como estrategias distintas para disponibilidad, lectura, capacidad y distribución de datos y carga.
Replicar significa mantener copias de los mismos datos. Particionar significa dividirlos en subconjuntos. Sharding distribuye esas particiones entre nodos. Cada técnica resuelve un problema diferente y añade nuevos modos de fallo.
Cuando los datos viven en un solo nodo, muchas garantías parecen simples: una escritura tiene una autoridad clara, una consulta ve una única copia y una transacción puede coordinar recursos localmente.
Al distribuirlos aparecen preguntas nuevas:
Distribuir datos puede aumentar capacidad, disponibilidad o cercanía geográfica, pero también introduce coordinación, staleness, fallos parciales y recuperación más compleja.
La replicación mantiene varias copias lógicas del mismo conjunto de datos.
Se utiliza para:
No aumenta automáticamente la capacidad de escritura. En muchos modelos, todas las escrituras siguen pasando por una autoridad.
Un líder acepta escrituras y propaga cambios a seguidores.
cliente escribe
→ leader confirma
→ log de cambios
→ follower A aplica
→ follower B aplicaUn usuario crea un pedido y luego es enviado a una réplica retrasada. Puede parecer que el pedido desapareció.
Soluciones:
El líder espera confirmación de una o más réplicas antes de responder.
write
→ leader persiste
→ follower confirma
→ respuesta al clienteReduce pérdida potencial si el líder falla, pero añade latencia y depende de disponibilidad de réplicas.
El líder responde antes de que seguidores confirmen.
write
→ leader persiste
→ respuesta
→ follower aplica despuésMejora latencia y disponibilidad de escritura, pero existe una ventana en la que el cambio puede perderse durante failover.
La decisión debe expresarse mediante RPO, latencia y tolerancia a indisponibilidad, no con “más seguro” o “más rápido”.
Varios líderes aceptan escrituras, normalmente por región o entorno desconectado.
región A leader ⇄ región B leaderAporta escritura local y tolerancia regional, pero permite conflictos.
Ejemplo:
A cambia email a x@example.com
B cambia email a y@example.comEl sistema debe decidir:
Para datos financieros o inventario, resolver por timestamp suele ser insuficiente porque pierde intención.
En un modelo leaderless, el cliente o coordinador escribe en varias réplicas.
N = 3 réplicas
W = 2 confirmaciones de escritura
R = 2 respuestas de lecturaLa regla R + W > N aumenta la posibilidad de intersectar una copia reciente, pero no garantiza por sí sola linearizability. Importan:
El lag es la distancia temporal o de posición entre líder y réplica.
Puede crecer por:
Métricas útiles:
Un valor global puede ocultar que una réplica específica está detenida.
Failover sustituye un nodo no disponible.
Pasos conceptuales:
El problema difícil no es iniciar otro proceso. Es distinguir fallo real de partición de red y evitar split brain.
Dos nodos creen ser líderes y aceptan escrituras divergentes.
Se mitiga con:
Un lock o lease expirado no basta si el nodo antiguo puede seguir modificando recursos. El receptor debe rechazar tokens de fencing antiguos.
Una réplica protege frente a fallo físico, pero reproduce:
Se necesitan backups aislados, retención, point-in-time recovery y pruebas de restore.
Particionar divide un conjunto de datos.
tabla orders
├── partición 2026-01
├── partición 2026-02
└── partición 2026-03Puede ocurrir dentro del mismo nodo o distribuirse entre varios.
Objetivos:
Divide valores contiguos: fecha, ID o región.
Ventajas:
Riesgo:
Aplica una función a la clave.
Ventajas:
Riesgo:
Un catálogo indica dónde vive cada clave o tenant.
Ventajas:
Riesgo:
Todos los datos de un tenant permanecen juntos.
Ventajas:
Riesgo:
Útil para logs, métricas y datos con retención.
Riesgo principal: todas las escrituras actuales pueden concentrarse en una partición.
Sharding distribuye particiones entre nodos independientes.
router
├── shard 1: tenants A–F
├── shard 2: tenants G–M
└── shard 3: tenants N–ZEl router necesita conocer la ubicación o calcularla.
El shard key condiciona:
Una buena clave suele tener:
No existe una clave perfecta.
Favorece operaciones locales por negocio, pero un tenant grande puede saturar un shard.
Distribuye pedidos, pero consultas por tenant pueden tocar muchos shards si la clave no incluye tenant.
Favorece rangos, pero concentra escrituras recientes.
tenant_id + bucket puede distribuir tenants grandes conservando algo de locality. Aumenta complejidad de routing y consultas.
Un hotspot aparece cuando una partición recibe carga desproporcionada.
Causas:
Mitigaciones:
Cada mitigación complica consultas o consistencia.
Si la clave de routing no está presente, el sistema puede enviar la consulta a todos los shards.
query global
→ shard 1
→ shard 2
→ shard 3
→ merge y ordenarProblemas:
Alternativas:
Cada shard indexa sus datos. Son simples de mantener, pero una búsqueda global requiere fan-out.
Un índice separado localiza registros entre shards.
Facilita consultas, pero introduce:
Una transacción distribuida requiere coordinación como two-phase commit u otro protocolo.
Costos:
Por eso se diseñan límites para mantener invariantes dentro de un shard cuando sea posible.
No se debe romper una invariante solo para evitar coordinación; quizá la elección de shard key sea incorrecta.
Al crecer, los datos deben moverse.
Estrategias:
Un flujo seguro puede ser:
crear destino
→ copiar snapshot
→ capturar cambios incrementales
→ verificar
→ cambiar lecturas
→ cambiar escrituras
→ retirar origenDurante la migración deben controlarse escrituras concurrentes y rollback.
Escribir en origen y destino puede parecer sencillo, pero una de las dos operaciones puede fallar.
Alternativas más seguras:
La migración necesita métricas de progreso, divergencia y lag.
DomiSys podría comenzar con una base compartida indexada por business_id.
Si algunos negocios crecen:
tenants pequeños → pool compartido
enterprise → shard o base dedicadaEl directorio de tenants decide routing. La aplicación debe evitar asumir que todos viven en la misma conexión.
Una estrategia híbrida conserva simplicidad inicial y permite aislamiento selectivo.
Puede perderse una escritura ya confirmada al cliente si no estaba replicada. Define RPO y política de promoción.
El usuario no ve su cambio. Aplica read-your-writes o UI pendiente.
Ambos aceptan cambios. Se necesita conflicto semántico o bloquear una región.
Una consulta global puede devolver resultados parciales. Decide si fallar todo, marcar parcial o usar datos antiguos.
Jobs, cachés y eventos deben utilizar routing actualizado. Un ID físico incrustado en mensajes antiguos puede romper procesamiento.
La copia compite por I/O y red. Usa throttling, ventanas, prioridad y observación.
Las réplicas de lectura pueden estar retrasadas. La aplicación debe conocer la garantía.
Replica errores lógicos. Mantén backups aislados y restaura de prueba.
Se paga complejidad sin necesidad. Primero optimiza consultas, índices, hardware, retención y caché.
Puede destruir locality y exigir fan-out para todas las consultas importantes.
La distribución por tenant parece uniforme en cantidad, pero no en carga o tamaño.
Mover datos sin checksums y reconciliación puede perder o duplicar registros.
Cuando necesitas tolerancia de nodo, lecturas adicionales o cercanía, aceptando semántica de lag.
Cuando volumen, retención o mantenimiento justifican dividir datos sin distribuir todavía.
Cuando un nodo o cluster no satisface capacidad o aislamiento y existe una clave de distribución compatible con el dominio.
tenant_id como shard key a un tenant muy grande?Consistencia, CAP y PACELC profundiza en las garantías observables cuando existen réplicas, particiones y decisiones entre coordinación, latencia y disponibilidad.