2. Infraestructura Técnica (Torrente Engine)
Para soportar un modelo financiero de alta transaccionalidad, que demanda garantías inquebrantables de inmutabilidad y capacidad para manejar concurrencia masiva, la infraestructura de Torrente fue concebida alejándose deliberadamente de los paradigmas monolíticos tradicionales, así como de las limitaciones inherentes a las redes públicas de blockchain de propósito general.
2.1. Filosofía de Diseño: Rust y Arquitectura Distribuida vs. Capa 1 EVM
Una decisión arquitectónica fundacional para el proyecto fue el desarrollo de un Core Ledger propietario escrito enteramente en el lenguaje de programación Rust, optando por una arquitectura distribuida interna en lugar de desplegar la lógica de negocio fundamental en una cadena de bloques pública compatible con la Ethereum Virtual Machine (EVM). Aunque el despliegue en una red de Capa 1 (L1) pública ofrece descentralización inherente y componibilidad nativa, introduce fricciones operativas inaceptables para una plataforma fintech de alta frecuencia que debe interactuar sincrónicamente con el mundo bancario tradicional. Las redes basadas en EVM sufren de alta volatilidad en los costos de transacción (gas fees), latencia impredecible en la finalidad de los bloques (block finality) y una vulnerabilidad latente a las reorganizaciones de cadena. Más críticamente, la transparencia pública e indiscriminada del estado on-chain entra en conflicto directo con las normativas de secreto bancario y la privacidad comercial requerida en las operaciones B2B confidenciales.
En agudo contraste, el ecosistema de desarrollo de Rust proporciona un entorno de abstracciones de costo cero, estricta seguridad de memoria sin la latencia impredecible de un recolector de basura (garbage collector) y un rendimiento transaccional sustancialmente superior. Evaluaciones comparativas demuestran que un motor contable desarrollado en Rust es capaz de analizar y validar libros mayores masivos entre diez y treinta veces más rápido que implementaciones equivalentes en lenguajes interpretados como Python. Adicionalmente, este enfoque optimiza drásticamente el consumo de recursos, utilizando típicamente entre tres y cinco veces menos memoria que sus contrapartes, gracias a la eficiencia de sus estructuras de datos. La elección de Rust permite a Torrente construir un motor de emparejamiento de doble entrada capaz de procesar validaciones en cuestión de milisegundos, manteniendo un perfil de ejecución altamente predecible. Este diseño se enmarca en un modelo de base de datos inmutable de estilo UTXO (Unspent Transaction Output) acoplado a un servicio centralizado, proporcionando los beneficios absolutos de la criptografía y la auditoría inmutable sin los compromisos de escalabilidad de una Capa 1 pública. Para cumplir con las exigencias de soberanía de datos impuestas por el regulador, Torrente emplea una Arquitectura Híbrida: el Core Ledger (PostgreSQL) y los datos confidenciales de los usuarios se alojan en servidores Tier III físicamente ubicados en el territorio nacional, mientras que las liquidaciones y anclajes criptográficos interactúan asincrónicamente con la red descentralizada Web3.
2.2. El Core Ledger, Inmutabilidad y PostgreSQL
El núcleo operativo de Torrente es su Core Ledger, diseñado bajo el principio contable universal de partida doble (double-entry bookkeeping). Esta premisa establece que cada movimiento de valor dentro del sistema requiere al menos dos asientos contables simultáneos: un débito y un crédito por el monto exacto, asegurando matemáticamente que la suma neta de todas las entradas sea siempre igual a cero. Esta restricción estructural imposibilita la creación o destrucción silenciosa de capital, garantizando que ninguna fracción monetaria pueda aparecer o desaparecer del ecosistema sin dejar un rastro auditable.
La inmutabilidad de este libro mayor se impone a nivel de la base de datos relacional, siendo PostgreSQL el motor seleccionado por su soporte nativo para aislamiento serializable y bloqueo a nivel de fila. En este esquema de event sourcing, una vez que un asiento (un posting) es registrado, jamás se actualiza ni se elimina (append-only canonical ledger). Si ocurre un error o se requiere un ajuste, el sistema debe emitir una nueva transacción reversa que compense el valor original, preservando la continuidad histórica del registro.
El esquema relacional fundamental de PostgreSQL para soportar este motor contable consta de tres dominios críticos interactuando en estricta sincronía:
| Entidad Lógica | Función y Diseño del Esquema PostgreSQL | Invariantes, Restricciones y Normalidad |
|---|---|---|
| Accounts | Representan entidades que almacenan valor. Identificadas mediante UUIDv7 (en lugar de UUIDv4) para asegurar un ordenamiento temporal natural, evitar la fragmentación masiva de los índices B-tree y optimizar la inserción. | Se dividen en cuentas de saldo normal deudor y saldo normal acreedor, por ejemplo, pasivos como las billeteras de los usuarios minoristas. |
| Transactions | Actúan como el agrupador lógico de los asientos de partida doble para un evento de negocio específico. Contienen metadatos cruciales de procedencia. | Imponen una clave única sobre el campo external_id para garantizar la idempotencia absoluta de las operaciones. |
| Postings | La tabla de registros append-only. Especifica la cuenta afectada, la dirección de la operación (DEBIT o CREDIT) y la magnitud del flujo. Utiliza tipos NUMERIC o DECIMAL de precisión arbitraria; jamás se emplean tipos de coma flotante (float). | Utiliza restricciones CHECK para forzar montos siempre positivos. Se apoya en una validación diferida (DEFERRED TRIGGER) al final del commit para verificar que la sumatoria de débitos y créditos sea cero. |
Resolución de Concurrencia y Condiciones de Carrera: El mayor riesgo técnico en una arquitectura financiera de alta frecuencia es la concurrencia destructiva. Escenarios donde dos subprocesos intentan simultáneamente deducir saldo de una misma billetera, o cientos de inversores compiten en milisegundos por la misma fracción remanente de una factura corporativa, pueden corromper el estado del sistema. Para resolver este desafío sin recurrir a mecanismos de bloqueo pesados (pessimistic locking puro a nivel de tabla) que paralizarían el rendimiento, Torrente emplea la directiva FOR UPDATE SKIP LOCKED integrada en PostgreSQL.
Cuando múltiples procesos distribuidores (workers) orquestan inversiones automáticas, ejecutan consultas estructuradas de la siguiente forma:
SELECT id
FROM invoices
WHERE status = 'AVAILABLE' AND yield_rate >= :target
ORDER BY id ASC
LIMIT 10
FOR UPDATE SKIP LOCKED;
La instrucción FOR UPDATE bloquea exclusivamente las filas recuperadas para que ninguna otra transacción concurrente pueda modificarlas, garantizando lecturas repetibles y previniendo colisiones de datos. Sin embargo, bajo cargas masivas, múltiples trabajadores seleccionando el mismo bloque generarían tiempos de espera severos y bloqueos mutuos (deadlocks). La sintaxis SKIP LOCKED neutraliza este riesgo al instruir al motor de la base de datos a ignorar las filas ya retenidas por otras transacciones, avanzando instantáneamente hacia los siguientes registros disponibles. Esta técnica transforma a PostgreSQL en un sistema de colas de trabajo transaccionales masivamente paralelizables, permitiendo que docenas de orquestadores asignen liquidez simultáneamente sin interbloqueos. Para asegurar aún más la estabilidad, la cláusula ORDER BY id ASC garantiza un ordenamiento determinista en la adquisición de bloqueos, práctica crítica recomendada para evadir el detector de deadlocks del motor relacional al interactuar con múltiples registros.
2.3. Orquestación Asíncrona (Event-Driven) y Colas de Mensajería
El ciclo de vida del capital en Torrente no se procesa mediante flujos de ejecución lineales o transacciones monolíticas masivas que bloquearían la interfaz del usuario. En su lugar, el sistema se apoya en una arquitectura asíncrona impulsada por eventos, utilizando infraestructuras de mensajería robustas como RabbitMQ o Apache Kafka.
Para garantizar la coherencia absoluta entre el estado mutado de la base de datos relacional y los eventos emitidos hacia el broker de mensajería, Torrente implementa el patrón de arquitectura Transactional Outbox. En sistemas distribuidos complejos, si el servicio central actualiza el saldo contable en PostgreSQL, pero el contenedor experimenta una falla de hardware milisegundos antes de lograr publicar el evento de “Fondeo Exitoso” en la cola de RabbitMQ, el ecosistema quedaría fracturado en un estado inconsistente, dado que los servicios periféricos (como el motor de notificaciones o el puente Web3) jamás se enterarían de la mutación.
El patrón Outbox erradica este vector de fallo almacenando el evento saliente dentro de la misma base de datos relacional, acoplado en la misma transacción ACID que altera los saldos contables:
- El orquestador inicia la transacción en la base de datos (BEGIN).
- Se insertan los asientos de partida doble en la tabla inmutable postings.
- En la misma instrucción, se inserta un registro serializado del evento (por ejemplo, InvoiceFunded) en una tabla segregada denominada outbox_events.
- Se ejecuta la confirmación transaccional (COMMIT). Si cualquiera de las inserciones previas falla, todo el bloque se revierte (ROLLBACK).
Posteriormente, un proceso secundario asíncrono, operando de manera continua y utilizando nuevamente la instrucción FOR UPDATE SKIP LOCKED sobre la tabla outbox_events para evitar superposiciones, lee estos registros consolidados, los transmite a RabbitMQ o Kafka y, únicamente tras recibir el acuse de recibo explícito (ack) del broker de mensajería, marca el registro relacional como completado. Esta topología provee garantías irrefutables de entrega de al menos una vez (at-least-once delivery), asegurando que ningún evento transaccional crítico perezca ante fallas de red. Dado que el paradigma at-least-once conlleva la posibilidad estadística de que un evento se transmita más de una vez en escenarios de recuperación de red, todos los microservicios consumidores operan bajo principios estrictos de idempotencia.
2.4. Smart Router & Auto-Allocation
El enrutador inteligente (Smart Router) funciona como el cerebro de asignación de capital dentro de Torrente. Es un algoritmo de emparejamiento de alta frecuencia diseñado para canalizar dinámicamente la vasta liquidez agregada proveniente de los usuarios con la función de auto-reinversión activa hacia las facturas comerciales B2B pendientes de financiamiento.
Cuando nuevos flujos de capital ingresan al sistema, o cuando las obligaciones previas maduran y liberan liquidez, el Smart Router se activa e ingiere una matriz compleja de variables estocásticas. En primer lugar, evalúa parámetros de riesgo y diversificación. El algoritmo impide activamente la concentración excesiva del portafolio de un único usuario minorista en un solo deudor corporativo, distribuyendo microscópicamente el capital a través de múltiples cadenas de suministro para diluir el riesgo de default. En segundo lugar, optimiza el tamaño de los lotes (batching). En lugar de procesar asignaciones individuales que saturarían el libro mayor, el sistema agrupa miles de microinversiones para cubrir instantáneamente facturas de alto valor nominal, reduciendo drásticamente la métrica de tiempo de mercado (Time-to-Fill) para la PYME cedente.
Finalmente, el motor cruza la tolerancia de plazo paramétrica del pool de capital con la duración (duration) específica de la factura comercial. Este proceso se ejecuta en ráfagas asíncronas de milisegundos, consumiendo liquidez del fondo general y materializando las mutaciones contables mediante las primitivas de validación del núcleo en Rust. El resultado es una orquestación perfecta que asegura que ninguna factura corporativa resulte sobrevendida (oversubscribed) y que el capital del inversor inicie su fase de devengo de intereses en el menor lapso técnicamente posible. Adicionalmente, el Smart Router está parametrizado para actuar de forma automatizada como Agente de Percepción, calculando, reteniendo y aislando los pasivos fiscales (como el IGTF) en tiempo real durante el desembolso, garantizando la indemnidad del margen corporativo.
Conclusión del capítulo
La infraestructura técnica de Torrente combina Rust, PostgreSQL, colas de eventos y un core ledger inmutable para sostener una operación financiera con alta velocidad, bajos niveles de error y capacidad para escalar. La idea central es sostener la contabilidad real sin comprometer la privacidad, la velocidad ni la trazabilidad.