Una fintech es, en esencia, una empresa de datos que casualmente mueve dinero. Su plataforma tiene que conciliar lo que en otros sectores va por separado: latencia de milisegundos para autorizar pagos, consistencia transaccional estricta para que ningún saldo cuadre mal, analítica masiva para el antifraude y el scoring, y trazabilidad regulatoria perpetua para el supervisor.
En este caso práctico —que cierra la Parte II de la Guía— se diseña ese stack de principio a fin a través de una fintech europea, recorriendo las decisiones, los trade-offs y los errores evitados: del ledger inmutable a la idempotencia, del tiering de almacenamiento a la resiliencia por niveles de criticidad. Incluye un incidente real que demuestra por qué las decisiones que parecían sobreingeniería cara fueron justo las que salvaron la operación.

Este capítulo ofrece una hoja de ruta completa para diseñar, implementar y verificar la estrategia de resiliencia y disaster recovery de la capa de datos. No se trata solo de tener backups —que, por supuesto, son imprescindibles— sino de construir un sistema en el que cada componente conoce su RTO (Recovery Time Objective) y su RPO (Recovery Point Objective), donde los procedimientos de recuperación están documentados en runbooks operativos verificados, y donde las pruebas de DR se ejecutan con la misma disciplina con la que se ejecutan las pruebas de rendimiento o los pen tests de seguridad..