Settlement Determinista: Por Qué la Latencia Sub-Milisegundo Importa en Finanzas

---

Una transferencia en vuelo es capital bloqueado. El saldo del emisor está debitado. El saldo del receptor aún no está acreditado. Esa diferencia, la brecha entre compromiso y disponibilidad, es dinero que ninguna parte puede usar.

A bajo volumen, el costo es invisible. A 1.000 transferencias por segundo con un tiempo de settlement promedio de 200 milisegundos, aproximadamente 200 transferencias están en vuelo en cualquier momento. A EUR 500 de valor promedio, eso son EUR 100.000 perpetuamente bloqueados en tránsito. Aumente la latencia de settlement a 2 segundos y el capital bloqueado sube a EUR 1.000.000. El costo de infraestructura de los servidores es un error de redondeo comparado con el costo de capital de la latencia.

Los bancos mantienen buffers de capital exactamente por esta razón. El buffer cubre la ventana de incertidumbre: el período entre "nos comprometimos a enviar" y "confirmamos que llegó." Reduzca la ventana, reduzca el buffer. La relación es directa.

Por Qué las Bases de Datos de Propósito General Alcanzan un Techo

La arquitectura predeterminada para un ledger financiero: PostgreSQL (o MySQL, o cualquier base de datos relacional), una tabla transactions, y lógica a nivel de aplicación para actualizar saldos. Para las primeras 10.000 cuentas y 100 TPS, esto funciona sin incidentes.

El techo aparece cuando las cuentas se vuelven "calientes." Una cuenta de cobro de comisiones tocada por cada transacción. Una cuenta de settlement que agrega todos los pagos salientes. Una cuenta de ingresos de plataforma que recibe cada split de comisión. Estas cuentas son accedidas por una proporción desproporcionada de transferencias, y cada acceso compite por el mismo bloqueo de fila.

PostgreSQL serializa escrituras a la misma fila. Bajo aislamiento SERIALIZABLE (el único nivel que previene todas las anomalías en workloads financieros), la detección de conflictos añade overhead adicional. Cuando dos transacciones concurrentes tocan la misma cuenta, una gana y la otra reintenta. Bajo carga, los reintentos se acumulan en cascada. El throughput se degrada no linealmente.

La Ley de Amdahl cuantifica el techo. Si el 5% de su workload es serializado, porque el 5% de las transferencias tocan una cuenta caliente, la aceleración teórica máxima de la paralelización es 20x. Añada más cores, más conexiones, más réplicas: el techo no se mueve. Es una propiedad del workload, no del hardware.

Los workarounds son familiares:

• Sharding, dividir el espacio de cuentas entre bases de datos. Pero las transferencias cross-shard (emisor en shard A, receptor en shard B) requieren transacciones distribuidas. Two-phase commit es lento y complejo. Ha cambiado contención de bloqueos por overhead de coordinación.
• Consistencia eventual, relajar el nivel de aislamiento, aceptar que los saldos pueden ser temporalmente inexactos, reconciliar después. En finanzas, "temporalmente inexacto" significa "el cliente ve un saldo que está mal." Inaceptable para cualquier sistema que muestre saldos en tiempo real.
• Bloqueo a nivel de aplicación, usar Redis o advisory locks para serializar acceso fuera de la base de datos. Ahora tiene dos sistemas que mantener consistentes, dos modos de fallo que manejar, y un gestor de bloqueos que se convierte en su propio punto único de contención.

Cada workaround resuelve el problema inmediato e introduce uno nuevo. El problema fundamental permanece: una base de datos de propósito general fue diseñada para manejar consultas arbitrarias contra esquemas arbitrarios. El settlement financiero no es un workload arbitrario. Es una operación específica, restringida y de alta frecuencia que se beneficia de un modelo de ejecución diseñado para ese propósito.

Lo Que una Engine Diseñada para el Propósito Hace Diferente

Una engine de settlement diseñada para workloads financieros toma tres decisiones arquitectónicas que una base de datos de propósito general no puede:

Records de tamaño fijo. Cada cuenta es exactamente 128 bytes. Cada transferencia es exactamente 128 bytes. Alineados con línea de caché. Sin campos de longitud variable, sin tablas TOAST, sin páginas de overflow. La CPU puede predecir patrones de acceso a memoria, y la engine de almacenamiento puede calcular la posición de cualquier record por aritmética. Sin lookup de índice requerido.

Procesamiento por lotes. En vez de adquirir y liberar un bloqueo por transferencia, la engine recoge transferencias en lotes, hasta 8.190 operaciones por lote, y las procesa en un solo paso. La contención de bloqueos es irrelevante porque no hay bloqueos. El lote es la unidad de trabajo. Todas las transferencias en un lote se aplican atómicamente.

El modelo de throughput se invierte: en vez de degradarse bajo concurrencia, mejora. Más clientes concurrentes significa lotes más llenos. Lotes más llenos significa mejor amortización del overhead por lote. El sistema se vuelve más rápido a medida que la carga aumenta, hasta los límites físicos de ancho de banda de memoria y I/O de disco.

Zero allocation, zero GC. Toda la memoria se aloca estáticamente al inicio. Ningún recolector de basura ejecuta durante la operación. Sin ciclos malloc/free. Sin fragmentación con el tiempo. La latencia es determinista: el tiempo para procesar un lote es función del tamaño del lote, no del estado del heap.

El resultado: latencia sub-milisegundo por transferencia con throughput predecible bajo carga. Sin curva de degradación. Sin spikes de tail latency por pausas de GC. Sin comportamiento sorpresa durante horas pico.

Lo Que el Settlement Determinista Habilita

El settlement sub-milisegundo no es una métrica de vanidad. Habilita cuatro capacidades operativas:

Visibilidad de saldos en tiempo real. Las transferencias internas se liquidan instantáneamente. Sin estado "pendiente" para movimientos on-platform. El saldo que el cliente ve es el saldo que tiene. Esto elimina toda una categoría de tickets de soporte ("¿Por qué mi saldo está mal?") y elimina la necesidad de la distinción "saldo disponible" vs. "saldo de ledger" para flujos internos.

Buffers de capital más pequeños. Menos incertidumbre significa menos reserva requerida. Si el settlement se completa en menos de un milisegundo, el capital en vuelo en cualquier momento dado es despreciable. El capital que de otro modo estaría bloqueado en buffers puede desplegarse productivamente.

Reconciliación más rápida. Cuando el settlement y el registro ocurren en la misma operación atómica, la reconciliación se convierte en un paso de verificación en vez de una investigación. El ledger y la engine de settlement concuerdan por construcción. Las discrepancias solo pueden surgir en la frontera, cuando sistemas externos (bancos, redes de clearing) están involucrados.

Testing de simulación determinista. Si la engine es determinista, mismas entradas siempre producen mismas salidas, en el mismo orden, puede reproducir workloads de producción en un entorno de prueba y obtener resultados idénticos. Así es como se prueba un sistema financiero bajo carga: no con mocks que aproximan comportamiento, sino con replay determinista que lo reproduce exactamente. Inyecte fallos (corrupción de disco, particiones de red, crashes de proceso) y verifique que la engine se recupera correctamente. Cada vez. Reproduciblemente.

El Problema de las Afirmaciones de Rendimiento

La mayoría de los proveedores de core banking publican números de throughput. "50.000 TPS." "100.000 cuentas por segundo." Estos números rara vez son significativos sin contexto.

Preguntas que importan:

• ¿Qué tipo de transacción? Una consulta de saldo no es un settlement. Una lectura no es una escritura. "TPS" sin especificar la operación no tiene sentido.
• ¿Qué distribución de cuentas? 1.000 TPS contra 1 millón de cuentas uniformemente distribuidas es trivial. 1.000 TPS contra 100 cuentas con distribución Zipfiana (cuentas calientes) es un workload completamente diferente.
• ¿Qué modelo de consistencia? "50.000 TPS" bajo READ COMMITTED es un número diferente que bajo SERIALIZABLE. Los workloads financieros requieren el aislamiento más fuerte. Cite el número a ese nivel.
• ¿Qué percentil? La latencia p50 le dice el caso típico. p99 le dice el peor caso 1-de-100. p100 le dice el peor caso real. Para settlement financiero, p99 y p100 son lo que importa. Un sistema que es rápido el 99% del tiempo y se detiene por 2 segundos en la solicitud 100 no es determinista.

Thought Machine (un proveedor de core banking) publica reportes de rendimiento certificados con journeys de prueba específicos, volúmenes de datos precargados, infraestructura documentada y verificación independiente. Este es el estándar que la industria debería adoptar: afirmaciones calificadas con metodología reproducible.

El enfoque honesto: publique su metodología de pruebas junto con sus números. Describa el workload. Nombre el nivel de aislamiento. Muestre la distribución de percentiles. Deje que los ingenieros evalúen la afirmación contra su propio perfil de workload. Los números de rendimiento no calificados son marketing. Los datos de rendimiento calificados son ingeniería.

---

Leer más: El Ledger | La Arquitectura de un Sistema Operativo Financiero

---

Fuentes:

• Amdahl, Gene M. "Validity of the single processor approach to achieving large scale computing capabilities." AFIPS '67, 1967.
• Jim Gray, "A Measure of Transaction Processing Power" (1985), benchmark TPC débito/crédito
• Thought Machine, "Vault Core Performance", metodología de benchmark certificada con verificación independiente
• "Gray Failure: The Achilles' Heel of Cloud-Scale Systems" (Microsoft Research, 2017), degradación silenciosa de hardware