Arquitectura multi-PSTI: cómo garantizamos 99.99% de uptime en PIX — y qué pasa cuando un PSTI cae

El problema del punto único de falla

La mayoría de los procesadores de pago se conectan a un solo PSTI (Participante Intermediario de Liquidación y Transferencia PIX). El PSTI es el puente entre su institución y el SPI (Sistema de Pagamentos Instantâneos) de BACEN — la infraestructura central que realmente liquida transacciones PIX.

Si su PSTI cae, su PIX cae. Cada pago saliente falla. Cada pago entrante rebota. Sus clientes ven "pago fallido" y se van a la competencia. Para un procesador de pagos manejando miles de transacciones por minuto, una caída de 30 minutos significa decenas de miles de pagos fallidos y cientos de clientes furiosos.

Y los PSTIs sí caen. Regularmente.

En 2024 solo, observamos 47 eventos de degradación de PSTIs entre los principales proveedores — desde cortes de 2 minutos hasta caídas completas de 4 horas. Algunos fueron ventanas de mantenimiento planificadas. Otros fueron no planificados — fallas de infraestructura, ataques DDoS, expiración de certificados, problemas de conectividad SPI.

La pregunta no es si su PSTI tendrá una caída. Es qué pasa con sus pagos cuando la tenga.

Por qué la mayoría de las instituciones son vulnerables

La arquitectura de PSTI único

La integración PIX típica se ve así:

Su sistema → PSTI → SPI (BACEN)

Una conexión. Un proveedor. Un punto de falla.

El enfoque de failover manual

Algunas instituciones tienen un PSTI de respaldo en papel. Cuando el primario cae, alguien (generalmente un ingeniero de guardia a las 3 AM) cambia el tráfico manualmente al respaldo. El proceso típicamente toma 15-30 minutos. Durante horas pico, eso es catastrófico.

El enfoque "hot standby"

Instituciones más sofisticadas mantienen una conexión PSTI secundaria caliente. Mejor, pero aún problemático:

• Latencia de detección: Los health checks típicamente corren cada 30-60 segundos
• Camino frío: La conexión standby no ha procesado tráfico real. Caches DNS pueden estar obsoletos. Connection pools pueden haber expirado
• Sin división de tráfico: Todo el tráfico se mueve de golpe

Nuestro enfoque multi-PSTI: active-active-standby

Revenu se conecta a 3 PSTIs simultáneamente:

• JD (Jdcloud) — Primario. Maneja ~70% del tráfico durante operación normal.
• C&M (Celcoin & Matera) — Secundario. Maneja ~30% del tráfico durante operación normal.
• Matera (SAF) — Standby caliente. Procesa un pequeño porcentaje de tráfico continuamente para mantener el camino caliente.

Esto no es failover. Es distribución activa de carga con rebalanceo dinámico.

Por qué active-active importa

Al rutear tráfico real a través de múltiples PSTIs simultáneamente, resolvemos el problema del camino frío. Cada conexión PSTI se ejercita continuamente. Connection pools están calientes. Caches DNS están frescos. Sesiones TLS están activas.

Distribución dinámica de tráfico

La distribución de tráfico es controlada por un router ponderado por salud. Cada PSTI tiene un puntaje de salud de 0 a 100, calculado a partir de:

• Latencia (p50, p95, p99): ¿Qué tan rápido responde el PSTI?
• Tasa de error: ¿Qué porcentaje de requests fallan?
• Tasa de timeout: ¿Qué porcentaje de requests expiran?
• Conectividad SPI: ¿Está el PSTI alcanzando el SPI exitosamente?
• Disponibilidad DICT: ¿Puede el PSTI resolver claves PIX vía DICT?

El router actualiza puntajes de salud cada 5 segundos y ajusta el tráfico proporcionalmente.

Circuit breakers: la primera línea de defensa

Cada conexión PSTI está envuelta en un patrón circuit breaker con tres estados:

CLOSED (operación normal)

Todos los requests fluyen. El circuit breaker monitorea tasas de error en una ventana deslizante de 30 segundos.

OPEN (PSTI caído)

Si la tasa de error excede 50% en la ventana de 30 segundos, o si 5 requests consecutivos fallan, el circuito se abre. Todo el tráfico se redirige inmediatamente a PSTIs saludables. Abrir el circuito toma < 500ms desde la detección de falla hasta la redirección del tráfico.

HALF-OPEN (prueba de recuperación)

Después de 30 segundos, el circuit breaker envía un request de prueba. Si tiene éxito, el circuito se cierra y el tráfico regresa gradualmente. Si falla, el circuito permanece abierto por otros 30 segundos.

Protección contra cascada

¿Qué pasa si 2 PSTIs fallan simultáneamente? El tercer PSTI recibe 100% del tráfico. Resolvemos esto con control de admisión. Cuando solo un PSTI está saludable, el router activa rate limiting. Transacciones excedentes se encolan en el sistema store-and-forward.

Store-and-forward: zero pérdida de transacciones

Cuando un pago PIX no puede entregarse a ningún PSTI, entra en la cola store-and-forward.

Cómo funciona

1. Store: El request de pago se persiste en una cola durable (respaldada por nuestro event store)

2. Monitor: Un proceso en background vigila los puntajes de salud de PSTIs cada 5 segundos

3. Forward: Cuando un PSTI se recupera, los pagos encolados se reenvían en orden FIFO, respetando rate limits

4. Confirm: Cada pago reenviado se confirma vía el flujo estándar pacs.002

Garantías de durabilidad

La cola store-and-forward es append-only y crash-safe. Si el proceso de Revenu se cae mientras procesa la cola, cada pago encolado se recupera al reiniciar. Ninguna transacción se pierde jamás.

Timeout y escalación

Los pagos en la cola tienen un TTL configurable (default: 5 minutos para PIX estándar, 30 segundos para PIX Saque/Troco). Si el TTL expira, el pago se marca como TIMEOUT y no se debitan fondos.

En 18 meses de producción, hemos tenido exactamente zero pagos que alcancen expiración de TTL.

Monitoreo de salud: ver problemas antes de que ocurran

Transacciones sintéticas

Cada 60 segundos, enviamos un pacs.008 sintético a través de cada PSTI — un pago PIX real de R$ 0,01 entre dos cuentas de prueba. Esto valida el camino completo end-to-end.

Si una transacción sintética falla, sabemos que el PSTI está degradado antes de que el tráfico real de clientes se vea afectado.

Detección de anomalías de latencia

Rastreamos percentiles de latencia por PSTI en ventanas de 1 minuto. Si la latencia p95 aumenta más de 2x comparado con el promedio móvil de 24 horas, se dispara una alerta de anomalía y el puntaje de salud se reduce — incluso si no hay errores.

Integración con status SPI

BACEN publica el estado operacional del SPI. Consumimos este feed y lo factorizamos en los puntajes de salud de PSTIs.

Integración DICT: resiliencia en resolución de claves PIX

DICT es el directorio centralizado de claves PIX de BACEN. Cuando un comprador inicia un pago PIX usando una clave, debe resolverse a una cuenta vía DICT.

Nuestra capa de cache DICT

Mantenemos un cache DICT local con TTL de 24 horas para lookups positivos y 5 minutos para lookups negativos. Si un PSTI falla durante resolución DICT:

1. Verificamos el cache local primero

2. Si cache miss, ruteamos la consulta DICT a través de un PSTI alternativo

3. Si todos los PSTIs están caídos para DICT, retornamos el resultado cacheado (si está dentro del TTL)

MED 2.0 y multi-PSTI: bloqueo de cadena de fraude entre proveedores

El MED 2.0 requiere bloqueo en cadena de fondos en hasta 5 niveles de dispersión. En una arquitectura multi-PSTI, esto crea un desafío de coordinación.

Una notificación de fraude puede llegar vía PSTI A, pero los fondos a bloquear pueden necesitar rastrearse a través de transacciones procesadas vía PSTI B. El ledger de Revenu proporciona una vista unificada — independientemente de qué PSTI procesó la transacción original, el ledger sabe a dónde fueron los fondos.

La arquitectura multi-PSTI realmente mejora la resiliencia MED 2.0 — si el PSTI que recibió la notificación de fraude se cae, los comandos de bloqueo pueden enviarse a través de PSTIs alternativos.

PIX Saque y PIX Troco: operaciones sensibles a latencia

PIX Saque y PIX Troco tienen requisitos de latencia más estrictos. El cliente está parado en un mostrador esperando.

Para estos tipos de transacciones, nuestro router multi-PSTI usa una estrategia de respuesta más rápida:

1. El request se envía a los 2 PSTIs más saludables simultáneamente

2. La primera respuesta exitosa se usa

3. La respuesta más lenta se descarta

Esta estrategia de hedging reduce la latencia p99 de ~800ms (PSTI único) a ~400ms (multi-PSTI con hedging).

Los números de producción

Después de 18 meses de arquitectura multi-PSTI en producción:

• 99.997% uptime — medido como "porcentaje de transacciones PIX procesadas exitosamente en 2 segundos"
• 0 transacciones perdidas — cada pago fue procesado o falló explícitamente con error claro
• 47 eventos de degradación de PSTI manejados automáticamente — zero requirieron intervención manual
• < 500ms tiempo de failover — desde circuito abierto hasta tráfico redirigido
• < 400ms latencia p99 para PIX Saque/Troco (ruteo hedged)
• 3 conexiones PSTI simultáneas — active-active-standby
• Transacciones sintéticas R$ 0,01 cada 60 segundos por PSTI
• Cache DICT 24 horas — zero fallas de pago relacionadas a DICT durante caídas de PSTI

Por qué esto importa más allá del uptime

La arquitectura multi-PSTI no se trata solo de disponibilidad. Se trata de confianza.

Cuando un marketplace procesa R$ 100 millones/mes en PIX, una caída de 30 minutos no es un incidente técnico — es una crisis de negocio. Vendedores pierden ventas. Compradores pierden confianza. La plataforma pierde credibilidad.

Construimos multi-PSTI porque creemos que la infraestructura de pagos debe ser invisible. No deberías saber que está ahí. Simplemente debería funcionar. Cada vez.

Y por 18 meses, lo ha hecho.