Arquitetura multi-PSTI: como garantimos 99.99% de uptime no PIX — e o que acontece quando um PSTI cai

O problema do ponto único de falha

A maioria dos processadores de pagamento conecta a um único PSTI (Participante Intermediário de Liquidação e Transferência PIX). O PSTI é a ponte entre sua instituição e o SPI (Sistema de Pagamentos Instantâneos) do BACEN — a infraestrutura central que efetivamente liquida transações PIX.

Se o seu PSTI cai, seu PIX cai. Cada pagamento de saída falha. Cada pagamento de entrada é recusado. Seus clientes veem "pagamento falhou" e migram para o concorrente. Para um processador de pagamentos lidando com milhares de transações por minuto, uma queda de 30 minutos significa dezenas de milhares de pagamentos falhos, centenas de clientes furiosos e um incidente de compliance que o BACEN vai te perguntar sobre.

E PSTIs caem. Regularmente.

Só em 2024, observamos 47 eventos de degradação de PSTIs entre os principais provedores — variando de blips de 2 minutos a quedas completas de 4 horas. Alguns foram janelas de manutenção planejadas (comunicadas 48 horas antes, durante horários de baixo tráfego). Outros foram não planejados — falhas de infraestrutura, ataques DDoS, expiração de certificados, problemas de conectividade com o SPI.

A pergunta não é se o seu PSTI vai ter uma queda. É o que acontece com seus pagamentos quando acontecer.

Por que a maioria das instituições é vulnerável

A arquitetura de PSTI único

A integração PIX típica se parece com isso:

Seu sistema → PSTI → SPI (BACEN)

Uma conexão. Um provedor. Um ponto de falha.

Quando o PSTI está saudável, funciona bem. Latência é baixa (tipicamente 200-500ms para um ciclo PIX completo). A integração é simples — uma API para aprender, um SLA para monitorar, um contrato para gerenciar.

Mas "funciona bem quando saudável" não é uma arquitetura — é uma oração.

A abordagem de failover manual

Algumas instituições têm um PSTI backup no papel. Quando o primário cai, alguém (geralmente um engenheiro de plantão às 3 da manhã) troca o tráfego manualmente para o backup. O processo tipicamente se parece com:

1. Alerta dispara: PSTI primário não responde (5-10 minutos para detectar)

2. Engenheiro de plantão acorda, lê o alerta, dá SSH no servidor (5-15 minutos)

3. Engenheiro muda a configuração do endpoint do PSTI (2-5 minutos)

4. Tráfego começa a fluir para o PSTI backup (imediato)

5. 30-60 minutos depois, primário recupera, engenheiro troca de volta

Tempo total de indisponibilidade: 15-30 minutos no mínimo. Durante horários de pico (almoço, dias de pagamento, sextas à noite), isso é catastrófico. Um marketplace processando R$ 500K/hora em PIX acabou de perder R$ 125K-250K em GMV — mais o dano de confiança.

A abordagem "hot standby"

Instituições mais sofisticadas mantêm uma conexão PSTI secundária quente — tecnicamente conectada mas sem processar tráfego. Quando o primário falha, um health check detecta a falha e um script automatizado troca o tráfego.

Melhor, mas ainda problemático:

• Latência de detecção: Health checks tipicamente rodam a cada 30-60 segundos. Um PSTI que falha entre checks não é detectado até o próximo check.
• Caminho frio: A conexão standby não processou tráfego real. Caches DNS podem estar obsoletos. Connection pools podem ter expirado. Sessões TLS podem precisar renegociação. As primeiras transações no caminho standby frequentemente falham.
• Sem divisão de tráfego: Todo o tráfego se move de uma vez. Se o PSTI standby não aguenta seu volume completo, você acabou de criar uma falha em cascata.

Nossa abordagem multi-PSTI: active-active-standby

A Revenu conecta a 3 PSTIs simultaneamente:

• JD (Jdcloud) — Primário. Lida com ~70% do tráfego durante operação normal.
• C&M (Celcoin & Matera) — Secundário. Lida com ~30% do tráfego durante operação normal.
• Matera (SAF) — Standby quente. Processa um pequeno percentual de tráfego continuamente para manter o caminho quente.

Isso não é failover. É distribuição ativa de carga com rebalanceamento dinâmico.

Por que active-active importa

Ao rotear tráfego real por múltiplos PSTIs simultaneamente, resolvemos o problema do caminho frio. Cada conexão PSTI é exercitada continuamente. Connection pools estão quentes. Caches DNS estão frescos. Sessões TLS estão ativas. Quando precisamos mudar tráfego, o PSTI receptor já está processando — apenas mandamos mais.

Distribuição dinâmica de tráfego

A distribuição de tráfego é controlada por um router ponderado por saúde. Cada PSTI tem um score de saúde de 0 a 100, calculado a partir de:

• Latência (p50, p95, p99): Quão rápido o PSTI está respondendo?
• Taxa de erro: Qual percentual de requests está falhando?
• Taxa de timeout: Qual percentual de requests está expirando?
• Conectividade SPI: O PSTI está alcançando o SPI do BACEN com sucesso?
• Disponibilidade DICT: O PSTI consegue resolver chaves PIX via DICT?

O router atualiza scores de saúde a cada 5 segundos e ajusta o tráfego proporcionalmente. Um PSTI com score de saúde 90 recebe o dobro de tráfego de um com score 45. Um PSTI com score abaixo de 10 recebe zero tráfego.

Circuit breakers: a primeira linha de defesa

Cada conexão PSTI é envolvida em um padrão circuit breaker com três estados:

CLOSED (operação normal)

Todos os requests fluem normalmente. O circuit breaker monitora taxas de erro em uma janela deslizante de 30 segundos.

OPEN (PSTI caiu)

Se a taxa de erro excede 50% na janela de 30 segundos, ou se 5 requests consecutivos falham, o circuito abre. Todo o tráfego é imediatamente redirecionado para PSTIs saudáveis. Nenhum request é enviado ao PSTI falho.

Abrir o circuito leva < 500ms da detecção da falha até o redirecionamento do tráfego. Seus clientes não percebem. Eles podem ver uma transação falha (a que trigou a abertura do circuito), mas a próxima já funciona em um PSTI diferente.

HALF-OPEN (teste de recuperação)

Após 30 segundos, o circuit breaker entra em estado half-open. Ele envia um único request de sonda ao PSTI falho. Se a sonda tem sucesso, o circuito fecha e o tráfego retorna gradualmente. Se falha, o circuito permanece aberto por mais 30 segundos.

Isso previne o problema thundering herd — se 1.000 transações estivessem enfileiradas e mandássemos todas para um PSTI se recuperando simultaneamente, provavelmente o derrubaríamos de novo.

Proteção contra cascata de circuit breaker

E se 2 PSTIs falham simultaneamente? O terceiro PSTI de repente recebe 100% do tráfego. Ele aguenta a carga?

Resolvemos isso com controle de admissão. Quando apenas um PSTI está saudável, o router ativa rate limiting para proteger o PSTI restante de sobrecarga. Transações excedentes são enfileiradas no sistema store-and-forward e processadas quando há capacidade disponível.

Na prática, nunca tivemos todos os 3 PSTIs falhando simultaneamente. Mas testamos. O sistema degrada graciosamente — pagamentos críticos (salários, ordens judiciais) têm prioridade, enquanto pagamentos de menor prioridade são enfileirados.

Store-and-forward: zero perda de transações

Quando um pagamento PIX não pode ser entregue a nenhum PSTI (todos os circuitos abertos, ou falha de rede transiente), ele entra na fila store-and-forward.

Como funciona

1. Store: O request de pagamento é persistido em uma fila durável (backed pelo nosso event store — a mesma infraestrutura de Event Sourcing que alimenta o ledger). O status do pagamento vira QUEUED.

2. Monitor: Um processo background monitora os scores de saúde dos PSTIs a cada 5 segundos.

3. Forward: Quando um PSTI se recupera (circuito fecha), pagamentos enfileirados são encaminhados em ordem FIFO, respeitando rate limits para não sobrecarregar o PSTI se recuperando.

4. Confirm: Cada pagamento encaminhado é confirmado via o fluxo padrão pacs.002. Se a confirmação falha, o pagamento re-entra na fila.

Garantias de durabilidade

A fila store-and-forward é append-only e crash-safe. Se o processo da Revenu crasha enquanto processa a fila, cada pagamento enfileirado é recuperado no restart. Nenhuma transação é jamais perdida — mesmo no pior cenário de falha simultânea de PSTI + crash do processo da Revenu.

Timeout e escalação

Pagamentos na fila têm um TTL configurável (default: 5 minutos para PIX padrão, 30 segundos para PIX Saque/Troco). Se o TTL expira:

1. O status do pagamento vira TIMEOUT

2. O comprador é notificado que o pagamento não pôde ser processado

3. Um incidente é criado no nosso sistema de monitoramento

4. Nenhum fundo é debitado (o lançamento contábil é revertido)

Em 18 meses de produção, tivemos exatamente zero pagamentos que atingiram expiração de TTL. A arquitetura multi-PSTI garante que pelo menos um caminho está sempre disponível dentro da janela de TTL.

Monitoramento de saúde: vendo problemas antes que aconteçam

Transações sintéticas

A cada 60 segundos, enviamos um pacs.008 sintético através de cada PSTI — um pagamento PIX real de R$ 0,01 entre duas contas de teste da Revenu. Isso valida o caminho completo de pagamento end-to-end: API → PSTI → SPI → DICT → SPI → PSTI → API.

Se uma transação sintética falha, sabemos que o PSTI está degradado antes que o tráfego real de clientes seja afetado.

Detecção de anomalias de latência

Rastreamos percentis de latência (p50, p95, p99) por PSTI em janelas de 1 minuto. Se a latência p95 aumenta mais de 2x comparada à média móvel de 24 horas, um alerta de anomalia dispara e o score de saúde é reduzido — mesmo se nenhum erro ocorreu ainda.

Isso captura degradações que não se manifestam como erros. Um PSTI pode ainda estar respondendo, mas com 3x a latência normal — o que significa que pagamentos do cliente levam 3 segundos em vez de 1 segundo. A detecção de anomalia reduz o tráfego para aquele PSTI antes que clientes comecem a reclamar.

Integração com status SPI

O BACEN publica o status operacional do SPI. Consumimos esse feed e incorporamos nos scores de saúde dos PSTIs. Se o próprio SPI está degradado (o que afeta todos os PSTIs igualmente), ativamos store-and-forward proativamente em vez de esperar por erros.

Integração DICT: resiliência na resolução de chaves PIX

DICT (Diretório de Identificadores de Contas Transacionais) é o diretório centralizado de chaves PIX do BACEN. Quando um comprador inicia um pagamento PIX usando uma chave (CPF, email, telefone, EVP), a chave precisa ser resolvida para uma conta via DICT.

A resolução DICT também depende da conexão PSTI. Se um PSTI falha, lookups DICT por aquele PSTI também falham.

Nossa camada de cache DICT

Mantemos um cache DICT local com TTL de 24 horas para lookups positivos (chave encontrada) e 5 minutos para lookups negativos (chave não encontrada). Quando uma chave é resolvida, o resultado é cacheado localmente.

Se um PSTI falha durante resolução DICT:

1. Verificamos o cache local primeiro

2. Se cache miss, roteamos a query DICT por um PSTI alternativo

3. Se todos os PSTIs estão fora para DICT, retornamos o resultado cacheado (se dentro do TTL) ou falhamos com erro claro

Isso significa que quedas de DICT não cascateiam em falhas de pagamento para chaves que foram vistas recentemente.

MED 2.0 e multi-PSTI: bloqueio de cadeia de fraude entre provedores

O MED 2.0 (Mecanismo Especial de Devolução) do PIX exige bloqueio em cadeia de fundos em até 5 níveis de dispersão quando fraude é detectada. Em uma arquitetura multi-PSTI, isso cria um desafio de coordenação.

Uma notificação de fraude pode chegar via PSTI A, mas os fundos a serem bloqueados podem precisar ser rastreados através de transações processadas via PSTI B. O ledger da Revenu fornece uma visão unificada — independente de qual PSTI processou a transação original, o ledger sabe para onde os fundos foram.

Bloqueio em cadeia MED 2.0 na nossa arquitetura:

1. Notificação de fraude recebida (via qualquer PSTI) → evento de domínio emitido

2. Rastreamento de fundos — Ledger rastreia o fluxo completo de fundos através de todas as transações (independente de PSTI)

3. Execução de bloqueio — Comandos de bloqueio são enviados pelo PSTI mais saudável

4. Confirmação — Confirmações de bloqueio são recebidas e reconciliadas contra o rastreamento

A arquitetura multi-PSTI realmente melhora a resiliência do MED 2.0 — se o PSTI que recebeu a notificação de fraude cai, comandos de bloqueio ainda podem ser enviados por PSTIs alternativos.

PIX Saque e PIX Troco: operações sensíveis a latência

PIX Saque (saque em estabelecimentos) e PIX Troco (troco com compra) têm requisitos de latência mais rigorosos que o PIX padrão. O cliente está de pé em um caixa esperando a transação completar. Um atraso de 5 segundos é inaceitável.

Para esses tipos de transação, nosso router multi-PSTI usa uma estratégia de resposta mais rápida em vez de distribuição ponderada por saúde:

1. O request de pagamento é enviado aos 2 PSTIs mais saudáveis simultaneamente

2. A primeira resposta bem-sucedida é usada

3. A resposta mais lenta é descartada (ou se ambos têm sucesso, a duplicata é tratada idempotentemente)

Essa estratégia de hedging reduz a latência p99 de ~800ms (PSTI único) para ~400ms (multi-PSTI com hedging) para operações PIX Saque/Troco.

Observabilidade: sabendo o que está acontecendo em tempo real

Dashboards

Cada PSTI tem um dashboard em tempo real mostrando:

• Score de saúde atual
• Percentual de distribuição de tráfego
• Percentis de latência (p50, p95, p99)
• Taxa de erro
• Estado do circuit breaker
• Profundidade da fila (store-and-forward)
• Taxa de sucesso de transações sintéticas

Alertas

Alertas multi-nível baseados em severidade:

• INFO: Anomalia de latência de PSTI detectada, score de saúde reduzido
• WARNING: Circuit breaker aberto em um PSTI, tráfego redistribuído
• CRITICAL: Dois PSTIs fora simultaneamente, store-and-forward ativado
• EMERGENCY: Todos os PSTIs fora, todo tráfego enfileirado (nunca disparado em produção)

Correlação de incidentes

Quando um incidente de PSTI ocorre, nosso sistema automaticamente correlaciona:

• Quais transações foram afetadas
• Quais transações foram automaticamente reroteadas
• Quais transações entraram na fila store-and-forward
• Impacto no cliente (quantos usuários finais experimentaram algum atraso)

Esse relatório de incidente é gerado automaticamente e pode ser enviado ao compliance do BACEN em minutos.

Os números de produção

Após 18 meses de arquitetura multi-PSTI em produção:

• 99,997% uptime — medido como "percentual de transações PIX processadas com sucesso em 2 segundos"
• 0 transações perdidas — cada pagamento foi processado ou falhou explicitamente com erro claro
• 47 eventos de degradação de PSTI tratados automaticamente — zero requereram intervenção manual
• < 500ms tempo de failover — de circuito aberto a tráfego redirecionado
• < 400ms latência p99 para PIX Saque/Troco (roteamento hedged)
• 3 conexões PSTI simultâneas — active-active-standby
• Transações sintéticas R$ 0,01 a cada 60 segundos por PSTI
• Cache DICT 24 horas — zero falhas de pagamento relacionadas a DICT durante quedas de PSTI

Por que isso importa além do uptime

A arquitetura multi-PSTI não é só sobre disponibilidade. É sobre confiança.

Quando um marketplace processa R$ 100 milhões/mês em PIX, uma queda de 30 minutos não é um incidente técnico — é uma crise de negócio. Sellers perdem vendas. Compradores perdem confiança. A plataforma perde credibilidade.

Quando um banco processa pagamentos de salário para 50.000 funcionários via PIX no dia 5 de cada mês, indisponibilidade não é opção. Esses pagamentos precisam acontecer — no horário, toda vez.

Nós construímos multi-PSTI porque acreditamos que infraestrutura de pagamentos deve ser invisível. Você não deveria saber que está lá. Deveria simplesmente funcionar. Toda vez.

E por 18 meses, funcionou.