Charding e replicação de banco de dados

(Secção Tecnologia e Infraestrutura)

Resumo breve

Para plataformas iGaming aumento do tráfego (taxas, depósitos, webhooks PSP, eventos de jogos) e requisitos de disponibilidade (≈99. 9–99. 99%) são rapidamente lavados para o limite de um BD. A replicação oferece escala horizontal de leitura e resistência a falhas; charding - escala horizontal de gravação e dados. A chave é comprometimento consciente PACELC (após a rejeição: CA/P, senão: Latency vs Consistency), SLO claro e disciplina de esquemas/chaves.

Termos e modelos

Replicar - Copiar dados entre nós.

Líder-Follower (Primary-Replica): uma gravação → muitas leituras.
Multi-Líder (Ativo-Ativo): gravações em várias regiões, conflitos/merj.
Consensus-replicação (Raft/Paxos, NewSQL): gravações quórumas (Cassandra/Scylla - quorum AP, CockroachDB/Yugabyte - quorum COP).
Sync/Semi-sync/Async: saldo de atraso vs RPO.
Charding - divisão horizontal de tabelas/chaves por chard.

Hash-charding (uniforme, faixa mais complexa).
Range-charding (faixas de chaves, risco de extremidade quente).
Consent hasing (adição suave/abaixamento de nódulos).
Geo-charding (por região/jurisdição).
Sharding funcional (por domínio: pagamentos/taxas/CRM).

Quando e o que escolher no iGaming

Apenas replicação (sem charding) - quando o problema principal é a leitura: fitas de eventos, relatórios, diretórios públicos. As gravações são colocadas em um único líder e as leituras em uma réplica.
Charding - quando a gravação/armazenamento é estreita: fluxo de apostas, transações de balanços, eventos desencadeados.

• Latidão para jogadores/PSP → leituras locais com réplicas.
• Regulação (localização de dados) → geo-charding.
• DR interregional → réplica asincrona + plano de mudança.

PACELC e propriedades de garantia

CAP: seleciona C (consistência) ou A (disponibilidade) na rede-liga.
PACELC: Sem falhas, selecionamos entre Latency (L) e Consistency (C).
Caminhos de dinheiro (saldo, débitos): normalmente C-orientado (COP/strict serializable ou Serializable + Idempotação de negócios).
Menos criteriosos (logs de cliques, diretórios): L-orientados (AP/EC, evolutivo).

Replicação: práticas

Leader–Follower

Gravações → líderes, leitores → réplicas (read escaling).
Leia com o líder para operações personalizadas ou espere pela liga (verificação de 'last _ committed _ lsn '/' wait _ for _ replay _ lag').
Semi-sync em vias críticas (redução da RPO com preço de latência).
Failover: automático (patroni/raft-coordenador) + fencing (para que não haja duplo líder).

Multi-Leader

Adequado para domínios separados e baixo conflito (por exemplo, conteúdo/configurações), mas não para uma única conta de jogador sem medidas especiais.
Políticas de merja: last-write-wins, CRDT, regras de domínio de consolidação.

Consensus/BB de quórum

Gravação com quórum (por exemplo, 'WRITE QUORUM'), leitura com quórum ('READ QUORUM') → consistência forte/configurável.
Leve em conta a latência mage-AZ/regiões e o custo de quórum.

Charding: estratégias e escolha da chave

Como selecionar a chave

Distribuição estável por player _ id/post _ id/bet _ id.
Evite as chaves monótonas (auto-increment) no range-charding - a cauda «quente».
Para pagamentos, muitas vezes 'player _ id' ou 'account _ id'; para logs - 'event _ time' + bucketing; para conteúdo - 'tenant _ id'.

Estratégias

Hash-charding player _ id: balanço em fluxo de apostas/balanços.
Range-charding hora para analistas/arquivos.
Geo-charding: Jogadores EU → EU-shard (conformidade com as leis locais).
Híbrido: hash dentro da região + geo por jurisdição.

Luta contra as chaves quentes

Key-salting (adicionar sal/bucket à chave).
Write-throttling é essencial, fila de comanda (serial executor).
Materializar «agregados» (balanço) em um estoque separado com uma fila de seqüência.

Operações de Cross-Shard

Transferência de dinheiro/compensação: evitar 2PC em vias quentes.
Saga Pattern: dividir em transações locais + ações compensatórias, idempotidade severa e outbox.
2RS/protocolos da comitiva: admissíveis (batches de back-office), mas caros por latência e resistência a falhas.
Projeções: apresentações de leitores (read models) para telas de entre domínios, atualizadas a partir de striptease.

Esquemas, índices e evolução

Versioning de padrão: migração de back-compat, função-flags no código.
Índices de chaves e solicitações frequentes; evitar cross-shard join (faça pré-join/denormização).
Para JSON/Dock Armazenamento - valide os circuitos (JSON-Schema/Protobuf) e TTL para coleções «ruidosas».

Escala online e resharding

Planeje um número N≫tekushcheye de shards virtuais (slots) → um rebalance flexível.
Consent hasing ou «nódulos virtuais» para adição suave de nós.

• dupla gravação (antigo + novo shard), validação da consistência;
• cópias de fundo dos chanks (logical dump/place move/streaming clone);
• alternar por «marcador» + janela de observação, depois retirar o duplo registro.
• Mudar de papel, drenar os conectores.

SLO, observabilidade e alerting

SLO gravação/leitura: p99 ≤ X ms em tabelas quentes, lag de ≤ Y segundos, disponibilidade de ≥ Z.
Métricas: TPS, p95/p99, reprodução lag, conflitante (multi-líder), retry rate, deadlocks, lock wait, cachê hit ratio, iOPS/latency disco.
Traçado: 'trace _ id' nas solicitações de banco de dados, associar a um corretor/pneu de evento.
Solicitações de canário e transmissões synthetic para o primeiro detetive de degradação.

Segurança e conformidade

Criptografia em paz e em trânsito (TLS), rotação de chaves.
RBAC/LCA, segmentação por domínios/tenentes, cluster de pagamento individual/CUS.
Localização de dados (EU/TR/LATAM) - combine geo-charding e políticas de retenção.
Auditoria: quem e o que leu/regras; camuflagem PII; exportar auditoria.

Bacaps, PITR, DR

Backaps completos + incorporados, armazenamento off-site.
PITR (point-in-time recovery) para clusters líder.

• Domínios críticos (saldo/pagamento) - RPO≈0 -30s (semi-sync ou shipping WAL frequente), RTO ≤ minutos com failover automático.
• Menos crítico - RPO até minutos/horas.
• Ensinamentos de DR (game day) e runbook documentado de mudança.

Desempenho e sintonização (breve)

Memória/dinheiro: aumente os tampões (shared buffers/inodb buffer pool), siga o cachê-hit ≥ 95%.
Registro/motor: NVMe rápido, volume separado sob WAL/redo.
Pool de conexões (PgBouncer/Hikari).
Planeador/estatística: Auto-análise/auto-teste (Postgres), compactação/sintonização GC (motores LSM).
Quórum/réplica-fator: equilíbrio entre p99 e resistência a falhas.

Topologias típicas para iGaming

1) Balanços e pagamentos (Circuito COP)

Líder-Follower na região do jogador, semi-sync para uma réplica próxima.
Hash-charding por 'matt _ id'.
Leitura «depois da gravação» - do líder; projeções em Redis para API-latency.
Outbox → pneu de evento para cálculos/analistas.

2) Histórico de Apostas/Eventos de Jogo (Logos Orientados AP)

Range-charding em tempo ou hash em 'player _ id' em um armazém invertebrado/LSM.
Réplicas asinhrônicas para relatórios/OLAP.
O Eventual consistency é aceitável, mais importante do que a largura de banda.

3) Perfis/CRM (Multi-region read, localização)

Geo-charding por jurisdição, réplicas locais para leitura.
Gravações através do líder mais próximo; região cruzada - asincrona + resolução de conflitos apenas para campos não-ríticos.

Exemplos (conceituais)

Postgres: sharding declaratório 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)';

Gravação quórum (pseudo)

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

Saga em vez de 2PC (simplificado)

1. Cancelar depósito em shard-A (idempotent).
2. Enviar o evento «quitado» → serviço de pagamento (shard-B).
3. Se o passo 2 estiver incompleto, compensará o passo 1 com o evento «retorno».

Folha de cheque de implementação

1. Defina os domínios de dados e SLO (p99, RPO/RTO).
2. Selecione um modelo de replicação (líder/follower, quórum) e uma estratégia de charding.
3. Fixe as chaves de charding e o padrão (inalterado!).
4. Digite a política de read-after-write e a rotação de leitura.
5. Projete um resharding online (chards virtuais, gravação dupla).
6. Garanta idempotidade e outbox para eventos/comandos.
7. Configure bacapes, PITR, DR. e exercícios regulares.
8. Liguem a vigilância, quóruns, chaves quentes, conflitos.
9. Documente o runbook: failover, split-brain, degradação.
10. Faça testes de carga/caos sob picos de mate.

Antipattern

Um «shard» gigante e «depois cortamos».
Join's de cross-chard no caminho quente do pedido.
Nenhuma política read-after-write (bags flutuantes).
Migração de esquemas de chaves de quebra.
Multi-líder para contas em dinheiro sem resolução rigorosa de conflitos.
Sem PITR/DR. - Não é possível recuperar de um erro lógico.

Resumo

A replicação resolve leitura e resistência a falhas, charding - gravações e volume. Arquitetura bem-sucedida em iGaming - nítidos compromissos SLO e PACELC, chaves de charding estáveis, coordenação de cross-chard mínima (saga em vez de 2PC), disciplina read-after-write, resharding online ajustado e exercícios DR regulares. Esta abordagem é dimensionada sob picos de torneios, suporta restrições regulatórias de localização de dados e permanece previsível em funcionamento.