Charding y replicación de bases de datos

(Sección: Tecnologías e Infraestructura)

Resumen breve

Para las plataformas iGaming, el crecimiento del tráfico (apuestas, depósitos, webhooks PSP, eventos de juegos) y los requisitos de disponibilidad (≈99. 9–99. 99%) caen rápidamente en el límite de un DB. La replicación proporciona escala de lectura horizontal y tolerancia a fallas; sharding - escala horizontal de registros y datos. La clave son los compromisos conscientes del PACELC (después del rechazo: CA/P, de lo contrario: Latency vs Consistency), los SLO claros y la disciplina de circuitos/claves.

Términos y modelos

Replicación: copia de datos entre nodos.

Leader-Follower (Primary-Replica): una escritura → muchas lecturas.
Multi-Leader (Active-Active): registros en varias regiones, conflictos/merge.
Consensus-replication (Raft/Paxos, NewSQL): registros de quórum (Cassandra/Scylla - quórums AP, CockroachDB/Yugabyte - CP-quórum).
Sync/Semi-sync/Async: balance de latencia vs RPO.
Charding - Partición horizontal de tablas/llaves por chardos.

Hash-sharding (uniformidad, rangos más complejos).
Range-charding (rangos de llaves, riesgo de extremos «calientes»).
Consistent hashing (adición suave/reducción del nodo).
Geo-charding (por región/jurisdicción).
Sharding funcional (por dominios: pagos/apuestas/CRM).

Cuándo y qué elegir en iGaming

Sólo replicación (sin sharding): cuando el problema principal es la lectura: cintas de eventos, informes, directorios públicos. Las entradas se colocan en un solo líder, las lecturas son con réplicas.
Sharding - Cuando el cuello de botella de escritura/almacenamiento: flujo de apuestas, transacciones de saldo, eventos desencadenantes.

Multi-region:

Latencia a jugadores/PSP → lecturas locales con réplicas.
Regulación (localización de datos) → geo-sharding.
DR interregional → Replica asíncrona + Plan de conmutación.

PACELC y propiedades de garantía

CAP: en una red dividida, seleccionamos C (consistencia) o A (disponibilidad).
PACELC: si no hay fallos, seleccionamos entre Latency (L) y Consistency (C).
Rutas monetarias (balance, deducibles): generalmente orientadas a C (serializable CP/strict o serializable + idempotencia empresarial).
Subsistemas menos críticos (registro de clics, directorios): L-orientado (AP/EC, eventual).

Replicación: prácticas

Leader–Follower

Escribir → leader, leer → replicar (leer escala).
Read-after-write: Para las operaciones personalizadas, lea con el líder o espere a que se produzca el corte (comprobación de 'last _ committed _ lsn'/' wait _ for _ replay _ lag').
Semi-sync en rutas críticas (reducción de RPO a costa de latencia).
Failover: automático (coordinador de patroni/raft) + fencing (para que no haya doble líder).

Multi-Leader

Adecuado para dominios divididos y bajo conflicto (por ejemplo, contenido/configuración), pero no para una sola cuenta de jugador sin medidas especiales.
Políticas de mercado: last-write-wins, CRDT, reglas de consolidación de dominio.

Consensus/Base de datos de quórum

Escritura con quórum (por ejemplo, 'WRITE QUORUM'), lectura con quórum ('READ QUORUM') → consistencia fuerte/personalizable.
Tener en cuenta la latencia de las regiones/AZ y el costo del quórum.

Charding: estrategias y selección de claves

Cómo seleccionar una clave

Distribución estable por player_id/ account_id/ bet_id.
Evite las llaves monótonas (auto-aumento) en range-sharding - cola «caliente».
Para pagos - a menudo 'player _ id' o 'account _ id'; para registros - 'event _ time' + bucketing; para contenido - 'tenant _ id'.

Estrategias

Hash-sharding por player_id: balance en el flujo de apuestas/balances.
Range-charding en el tiempo para análisis/archivos.
Geo-sharding: EU-players → EU-shard (cumplir con las leyes locales).
Híbrido: hash dentro de la región + geo por jurisdicción.

Lucha contra las llaves «calientes»

Key-salting (añadir sal/bucket a la llave).
Write-throttling por entidad, command queue (executor serial).
Materializar los «agregados» (balance) en un setor separado con una cola de secuencia.

Operaciones cruzadas

Transferencia de dinero/compensación: evite 2PC en las rutas calientes.
Patrón de saga: dividir en transacciones locales + acciones compensatorias, idempotencia rígida y outbox.
2RS/protocolos de commita: permitidos puntualmente (batches de back-office), pero costosos en latencia y tolerancia a fallas.
Proyecciones: vistas de lectura (read models) para pantallas entre dominios, actualizadas desde stream.

Esquemas, índices y evolución

Versionar esquema: migraciones de back-compat, feature-flags en código.
Índices de claves de charding y consultas frecuentes; evitar la cruz-shard join (hacer pre-join/desnormalización).
Para almacenamiento JSON/Dock: valide los esquemas (JSON-Schema/Protobuf) y TTL para colecciones «ruidosas».

Zoom y resharding en línea

Planifique N≫tekushcheye el número de chardos virtuales (slots) → un reequilibrio flexible.
Consistent hashing o «nodos virtuales» para agregar nodos de forma suave.

Recarga en línea:

doble registro (antiguo + nuevo shard), validación de consistencia;
copias de fondo de las chancas (logical dump/table move/streaming clone);
cambiar por «marcador» + ventana de vigilancia, luego quitar la grabación doble.
Mover un líder sin tiempo de inactividad: cambiar roles, drenar conectores.

SLO, observabilidad y alerting

SLO de escritura/lectura: p99 ≤ X ms en tablas calientes, réplicas lag válidas ≤ Y segundos, disponibilidad ≥ Z.
Métricas: TPS, p95/p99, replication lag, conflictividad (multi-leader), retry rate, deadlocks, lock wait, cache hit ratio, disco IOPS/latency.
Seguimiento: 'trace _ id' en solicitudes de BD, asociar con el bróker/bus de eventos.
Consultas canarias y transacciones synthetic para el Niño Temprano de la Degradación.

Seguridad y cumplimiento

Cifrado en reposo y en tránsito (TLS), rotación de claves.
RBAC/ACL, segmentación por dominios/tenantes, clústeres individuales para pagos/CUS.
Localización de datos (EU/TR/LATAM): combina geo-charding y políticas de retención.
Auditoría: quién y qué leyó/reglas; enmascaramiento PII; exportación de auditoría.

Backups, PITR, DR

Backups completos + incrementales, almacenamiento offsite.
PITR (recovery point-in-time) para clústeres líderes.

RPO/RTO:

Dominios críticos (balance/pago): RPO≈0 -30s (semi-sync o spip WAL frecuente), RTO ≤ minutos con failover automático.
Menos crítico: RPO hasta minutos/horas.
Ejercicios de DR (día del juego) y runbook de conmutación documentado.

Rendimiento y afinación (breve)

Memoria/caché: aumente los búferes (buffers compartidos/innodb buffer pool), siga cache-hit ≥ 95%.
Registro/motor: NVMe rápido, volumen separado bajo WAL/redo.
Agrupación de conexiones (PgBouncer/Hikari).
Planificador/estadístico: autovanálisis/autovacuum (Postgres), Compactación/afinación GC (motores LSM).
Quórum/factor de réplica: equilibrio entre p99 y tolerancia a fallas.

Topologías típicas para iGaming

1) Balances y pagos (circuito CP)

Leader-Follower en la región del jugador, semi-sync a una réplica cercana.
Hash-sharding por 'account _ id'.
Las lecturas «después de escribir» son del líder; proyecciones en Redis para la API-latencia.
Outbox → un bus de eventos para cálculos/análisis.

2) Historial de apuestas/eventos de juego (registro orientado a AP)

Range-sharding por tiempo o hash por 'player _ id' en el almacén de columnas/LSM.
Réplicas asíncronas para informes/OLAP.
La consistencia eventual es aceptable, el ancho de banda es más importante.

3) Perfiles/CRM (lectura multirregional, localización)

Geo-sharding por jurisdicción, réplicas locales para lecturas.
Registros a través del líder más cercano; región cruzada - asíncrono + resolución de conflictos sólo para campos no críticos.

Ejemplos (conceptuales)

Postgres: charding declarativo por 'player _ id'

sql
CREATE TABLE player_wallet (
player_id BIGINT NOT NULL,
balance_cents BIGINT NOT NULL,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (player_id)
) PARTITION BY HASH (player_id);

CREATE TABLE player_wallet_p0 PARTITION OF player_wallet FOR VALUES WITH (MODULUS 32, REMAINDER 0);
--... p1..p31

-- Репликация: публикация WAL на реплики, синхронность для «горячего» региона.
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (replica_eu1, replica_eu2)';

Registro de quórum (pseudo)


WRITE CL=QUORUM  -- запись подтверждена большинством реплик
READ CL=LOCAL_QUORUM -- локальный кворум для низкой задержки

Saga en lugar de 2PC (simplificada)

1. Cancelar depósito en shard-A (idempotent).
2. Enviar evento «retirado» → servicio de pago (shard-B).
3. Si el paso 2 falla, compense el paso 1 con un evento de «devolución».

Lista de comprobación de implementación

1. Defina los dominios de datos y SLO (p99, RPO/RTO, lag réplicas).
2. Seleccione el modelo de replicación (leader/follower, quórum) y la estrategia de charding.
3. Fije las llaves de charding y el diagrama (¡inmutable!).
4. Escriba read-after-write directivas y enrutamiento de lectura.
5. Diseñe la recarga en línea (bufandas virtuales, grabación doble).
6. Garantizar idempotencia y outbox para eventos/equipos.
7. Configurar los backups, PITR, DR y enseñanzas regulares.
8. Habilite la observabilidad: trago, quórums, llaves calientes, conflictos.
9. Documenta runbook: failover, split-brain, degradación.
10. Realice pruebas de carga/caos bajo los picos mate.

antipatterny

Un chard gigante «para todo» y «luego vamos a cortar».
Join's cross-chard en la ruta de acceso de la consulta.
No hay ninguna política de lectura después de escribir (bugs flotantes).
Migraciones de esquemas «rompiendo» las claves de sharding.
Multi-líder para cuentas monetarias sin resolución estricta de conflictos.
Sin PITR/DR: es imposible recuperarse de un error lógico.

Resultados

La replicación resuelve las lecturas y la tolerancia a fallas, las escrituras sharding y el volumen. La arquitectura exitosa en iGaming es un claro compromiso SLO y PACELC, claves de sharding estables, coordinación cruzada mínima (saga en lugar de 2PC), disciplina read-after-write, reciclaje en línea depurado y DR regulares Enseñanzas. Este enfoque escala los picos de los torneos, resiste las restricciones regulatorias de localización de datos y sigue siendo predecible en funcionamiento.