corebank

Hacía falta que ninguna operación pudiera dejar una cuenta en negativo. No «que sea difícil»: que no exista un camino de código capaz de hacerlo, incluido el que yo escriba el mes que viene sin acordarme de esta regla.

Un if saldo < monto en la capa de servicio, más una columna balance en Postgres. Es lo que hace casi todo el mundo y pierde por una razón concreta: la validación cubre las rutas que existen el día que se escribe. La ruta nueva, el script de migración de datos, el endpoint interno de ajuste — cada uno es una oportunidad de omitirla. Y la columna balance introduce una segunda fuente de verdad que puede discrepar del historial que supuestamente la explica.

Ningún camino de aplicación puede omitir la comprobación porque no hay comprobación que omitir. El costo es real y son dos cosas: obliga a una cuenta de patrimonio como contraparte —los depósitos debitan world, los retiros lo acreditan— y renuncia a consultar saldos con SQL ad-hoc, porque el saldo no está en Postgres. Cuando quiero un saldo, se lo pregunto al ledger.

Los montos entran por JSON, que no distingue entre un número entero y uno de punto flotante. Había que convertirlos a la unidad mínima sin perder un centavo en el camino.

float64(8.87) * 100 no da 887. Da 886, porque 8,87 no tiene representación exacta en binario y el producto cae apenas por debajo. Un centavo por transacción, silencioso, y en un ledger de doble entrada un centavo que no cuadra es un asiento que no cierra.

Decodificar a float64 y redondear al final, que es lo que hace el camino por defecto de cualquier librería JSON. Y también un tipo decimal de terceros: resuelve la aritmética pero no el borde que importa, porque el flotante ya se perdió en el decodificador antes de que el decimal exista.

Hay un UnmarshalJSON a mano que la mayoría de la gente consideraría innecesario, y una prueba que fija exactamente la diferencia entre 886 y 887 para que nadie lo «simplifique» más adelante. El costo es esa complejidad extra en el borde del sistema, concentrada en un archivo, a cambio de que el resto del código no tenga que pensar en el tema nunca.

El ledger guarda el movimiento del dinero; Postgres guarda todo lo demás — quién es el usuario, cómo se llama la cuenta, qué decía la descripción del movimiento. Una operación escribe en los dos, y no existe una transacción que abarque ambos.

El problema clásico: si el proceso muere entre las dos escrituras, ¿qué quedó? Un movimiento en el ledger sin fila que lo explique, o una fila que promete un movimiento que nunca ocurrió.

Un commit en dos fases entre los dos motores, que exige que los dos lo soporten y añade un coordinador que también puede caerse. Y un outbox con un worker, que es la respuesta correcta a escala; esperaría que añadiera latencia, y es una pieza más que mantener para un problema que aquí se resuelve con un identificador determinista.

Los reintentos son seguros por construcción: reintentar es escribir el mismo identificador, y el ledger rechaza el duplicado. Y hay un proceso de reconciliación que recorre las filas cuyo desenlace nunca se registró, lee el ledger y hace que la fila coincida. Nunca mueve dinero — sólo anota lo que el ledger ya hizo. El costo es que ese proceso existe y hay que entenderlo: un bug ahí puede reportar mal un movimiento, pero no puede perderlo ni duplicarlo.

El sistema tiene un asistente que opera cuentas en lenguaje natural: «retira 250 dólares», «pásale 80 a mi cuenta de ahorros». Un modelo de lenguaje decidiendo movimientos de dinero es exactamente el tipo de cosa que no puede salir bien por accidente.

Filtrar la salida del modelo —revisar lo que pide y bloquear lo peligroso— que es la respuesta habitual y pierde porque es una lista negra: protege de lo que se te ocurrió, y la inyección de prompts consiste precisamente en lo que no se te ocurrió. Y también una tabla propia de pendientes con un cron que limpie los vencidos, que funciona pero añade un proceso que puede fallar en silencio.

El hold lo expira el propio ledger cuando pasa su tiempo de vida, así que no hay proceso de limpieza: no existe el trabajo en segundo plano que podría caerse. La inyección de prompts deja de importar, porque lo peor que consigue un atacante es preparar una operación que el titular tiene que confirmar con su propia sesión. El costo es que la conversación tiene un paso más: el asistente nunca completa nada solo, y eso se siente en la interfaz.

Cada mensaje al asistente cuesta dinero real. Una demo pública con un formulario de registro abierto es una invitación a que alguien gaste mi presupuesto por mí.

Leer el contador, comparar en Go y escribir el nuevo valor: la carrera clásica, y con varias peticiones concurrentes el tope se pasa. Y un límite por IP, que mide la cosa equivocada — no me importa cuántas peticiones haga alguien, me importa cuánto cuestan.

El presupuesto aguanta concurrencia porque el chequeo y el incremento son la misma operación, y hay una prueba con -race que lanza goroutines contra un tope pequeño para demostrarlo. Como el gasto se reserva con una estimación alta y se liquida con el costo real, la interfaz tiene cuatro estados en vez de un booleano, y dice cuál motor respondió. También existe un proveedor basado en reglas, así que la aplicación funciona con la clave de API vacía. El costo es que «¿está disponible el asistente?» dejó de tener una respuesta de sí o no.