Como construir fail-safe processamento milhões de transações por dia

Texto completo do artigo

💡 Material técnico para os comandos de alimentos e plataforma fintech/jogos e setores adjacentes. Não um apelo para o jogo. Por «transações», compreendemos as transações em dinheiro/conta (débito, pagamento, transferência, setlment, reembolso).

1) O que significa fail-safe para transações

Fail-safe é quando qualquer situação falha leva a uma parada segura ou a uma condição compensável sem perda de dinheiro e dados. Objetivos:

«Débitos duplos/créditos» = 0.
Transações/eventos perdidas = 0.
SLO previsível de latência/entrega, regimes nítidos de degradação e DR..

A base são os invariantes em dinheiro (a verdade do balanço em um único lugar), a idempotidade, a entrega consistente de eventos.

2) Princípios arquitetônicos (curta)

1. Single six of truth: balanço e contabilidade - em Ledger/Wallet. Os serviços ao redor mantêm o estado dos processos, não o dinheiro.

2. Idempotency everywhere: Todas as operações de «gravação» aceitam «Idempotency-Key»; a repetição devolve o mesmo resultado.

3. Evento com garantia de entrega: outbox/CDC, filas, DLQ, deadup.

4. Sagas e compensações, não «redações manuais».

5. Back-pressure e prioridades: o sistema desacelera, mas não desmorona.

6. Observabilidade padrão: logs estruturados, trailing, métricas.

7. Multi-região e DR.: ativo-ativo/ativo-passivo, exercícios regulares.

3) Topologia arbitral


Edge/API GW ──Command API ──App Service (Sagas)
│           │
│         (Outbox TX)

RateLimit     Outbox Table ──Publisher ──Kafka/Pulsar ──Consumers
│                      │
WAF                     └─DLQ/Replay
│
└─Ledger/Wallet (ACID, idempotent debit/credit)
│
└─CDC/Changefeed ──DWH/BI/Recon

Locais-chave: Outbox (registro atômico do comando e «rascunho» do evento), Publisher (exatamente uma entrega), Consumers (Idempotentes, com chave de dedução), DLQ/Replay (repetições controladas).

4) Invariantes em dinheiro e coerência

A verdade do balanço é Ledger (ACID, transações seriadas ou ordenamento rigoroso).

Comandos em dinheiro: 'debit', 'credit', 'hold',' commit ',' rollback 'são idimpotentes.

Os processos combinados são construídos como sagas:

'autorize' setle credit '(depósito/setlment),' request submit massled/failed '(pagamento/retirada),' refund/void '(compensações).
Não há nenhuma edição direta do balanço para contornar o Ledger.

5) Idempotidade: design de chaves

A chave deve identificar claramente a operação de negócios:

`bet_id+amount+currency`, `payment_intent+capture_id`, `payout_id`, `chain_txid`.
Armazenar resultado por chave (response cachê). A repetição com a mesma chave → o mesmo body/status.
Controle a discrepância: chave igual à outra soma de → 'IDEMPOTENCY _ MISMATCH'.

6) Filas, ordem e dedução

Os efeitos exactly-once não são alcançados pelo transporte, mas por consumers idumpotentes + armazenamento LRU/Redis/DB c TTL.

Mantenha a ordem da chave (partition key = 'account _ id/round _ id/player _ id').

As chaves «heterogéneas» incluem a versionização do estado e os switches (state machine per entity).

O DLQ é obrigatório: após N tentativas - em um assunto isolado com uma causa humana.

7) Outbox/CDC: por que os eventos não se perdem

Como parte de uma transação no banco de dados do serviço, gravamos uma mudança de negócio e uma gravação em outbox.

Publisher individual lê outbox e publica em um pneu de confirmação.

Alternativa: CDC (Mudança Data Capture) em nível de BD (Debezium/logs de replicação).

Não há «logs de eventos» a passar por uma transação é uma fonte de perdas.

8) Back-pressure e prioridades

Toquetes e quotas de entrada (per tenant/brand/region).

Filas de prioridade, caminhos de dinheiro acima da promo/telemetria.

Sobrecarga: modos 'no new sessions/requests', congelamento de fichas secundárias, preservação do núcleo.

Degradação automática: reduzir a frequência de tarefas de fundo, expandir dinamicamente os workers críticos.

9) Sustentabilidade multiregional

Ativo para API e filas, local Ledger (ou global com charding para região/moeda).

Data residency: dinheiro/PII/revistas não são quebradas sem regras explícitas.

A replicação de eventos interregionalmente é asincrônica, com «region».

RPO/RTO: curte RPO ≤ 5 minutos, RTO ≤ 30 minutos; Verifique regularmente.

10) SLO/SLI e dashboards

Referências (exemplo):

p95 'autorize/debit/credit' <150-300 ms (caminho interno).
pen5 end-to-end «komanda→sobytiye no pneu» <1-2 s.
Entrega de webhooks/eventos externos p99 <5 min
«Transações perdidas/duplicadas» = 0 (verificações contratuais).

Métricas: latency p50/p95/p99, error-rate (4xx/5xx/business), consumer/queue lag, retry storms, setle lag, webhook lag, tamanho DLQ, frequência 'IDEMPOTENCY _ MISMATCH'.

11) Observação e auditoria

Logs JSON estruturados com 'trace _ id', 'idempotency _ key', ID de negócios, códigos de erro.

OpenTelemetry: Trailing HTTP/gRPC/DB/pneus, span sags.

Auditoria WORM: registros de alterações críticas imutáveis (limites, chaves, configs promocionais/jackpots).

Camuflagem PII/segredos, baquetes regionais, RBAC/ABAC para acesso aos logs.

12) Testes de confiabilidade

Testes contratuais: repetição/duplicação, out-of-order, idempotação, dedução.

Cargas: perfil de pico (x10), resistência de filas e BD.

Aquelas malas de caos, a queda do Ledger/carteira, as filas/regiões, atrasos de CDC, «tempestade» de retais.

Game Days: exercícios regulares de DR. e incidentes, com medição MTTR.

13) Armazéns e dados

OLTP para dinheiro: BB transacionado (RPO≈0), índices rigorosos, níveis seriados para entidades críticas.

O cash (redis) é apenas para acelerar, não para «verdade». TTL + jitter, proteção contra cachê estampede.

OLAP/DWH - para relatórios/analistas. Fluxo de CDC/pneu, sem carga de OLTP.

Os circuitos de dados são versionizados; migração sem downthame (expand/contract).

14) Orquestração de Retrações

Backoff exponencial + jitter, deadline/timeout em RPC.

Repetição Idumpotente em cada camada (cliente → serviço → consumidor).

Quotas de retraí, proteja-se contra «tempestades» (circuito breaker, hedged requests, se apropriado).

Replay de DLQ apenas para janelas «seguras», com limitação de velocidade.

15) Segurança dos transportes

mTLS S2S, tokens curtos (OAuth2 CC), assinaturas de corpos (HMAC/EdDSA) para webhooks.

Segredos em Vault/HSM, rotação, chaves per brand/region.

Políticas least privege, «quatro olhos» para operações manuais.

16) Contratos (fatias)

Comando de débito Idumpotente


POST /v1/wallet/debit
Headers: X-Idempotency-Key: debit_pi_001, X-Trace-Id: tr_a1b2
{
"account_id":"acc_42",  "amount":{"minor_units":5000,"currency":"EUR"},  "reason":"payout",  "reference_id":"po_001"
}
→ 200 { "status":"committed", "entry_id":"e_77" }
(repetição → mesma resposta)

Evento de outbox

json
{
"event_id":"uuid",  "event_type":"wallet. debit. committed",  "occurred_at":"2025-10-23T16:21:05Z",  "account_id":"acc_42",  "amount_minor":5000,  "currency":"EUR",  "reference_id":"po_001",  "idempotency_key":"debit_pi_001",  "schema_version":"1. 3. 0"
}

17) Folhas de cheque

Plataforma/operadora

Verdade de equilíbrio - um Ledger; não há caminhos de volta.
Todas as operações write com 'Idempotency-Key'; armazenado com a chave.
Outbox/CDC para todas as gravações de domínio, DLQ e replay controlado.
Filas de prioridade, back-pressure, modos de degradação.
Partition-keys selecionados por chave de negócio; os consumidores são idoneos.
SLO-dashboard, OpenTelemetry, auditoria WORM.
Ensinamentos DR/xaoc regulares, testes contratuais/de carga.
Data residency, criptografia, Vault/HSM, rotação de chaves.

Provedores/integração

Envio 'Trace-Id '/' Idempotency-Key', pronto para ser entregue novamente.
Os webhooks são assinados e deduzidos.
Versões de esquema/contrato são cumpridas (semver, deprecation).

18) Bandeiras vermelhas (anti-pattern)

O equilíbrio é alterado por webhoop sem comando no Ledger.

Falta de Idempotação → cancelamentos duplos/empréstimos.

Publicar eventos contornando outbox/CDC.

Monólito sem back-pressure, o pico de tráfego está a vazar tudo.

Mistura de OLTP e relatórios: BI bate no banco de combate.

Falta de DLQ/réplica; Um erro silencioso.

Não há isolamento regional PII/dinheiro; chaves compartilhadas em várias marcas.

Edição manual de balanços/estatais no banco de dados.

19) Resultado

Fail-safe processamento de milhões de transações por dia é sobre invariantes e disciplina: uma única fonte de verdade, comandos idimpotentes, sagas e outbox/CDC, ordem e dedução em filas, observabilidade e degradação controlada. Adicione mandatos de acesso, práticas de DR. e exercícios regulares - e receba um sistema onde o dinheiro se move rápido e apenas uma vez, os eventos não se perdem, e o aumento do tráfego e as falhas se tornam riscos controláveis em vez de surpresas.