Imagine que se embarca en un viaje para abordar las complejidades de la integración de los bancos en su sistema. Empiezas con una idea sencilla: recopilar, almacenar y presentar datos. Pero el panorama es cambiante, con innumerables incógnitas acechando en cada esquina.
Así que toma una decisión: Mantenerlo sencillo y centrada en las necesidades actuales. Tu solución debe ser como un organismo vivo, que se adapta constantemente a su entorno. Es parecido al concepto de algoritmo genético, en el que las soluciones evolucionan con el tiempo, aprendiendo de los errores y mejorando con cada iteración.
Imagínatelo así: cada generación de tu solución es como un nuevo capítulo de una historia. Empiezas con lo que funciona, pero siempre estás abierto a nuevos retos y experiencias. Y, como en una buena historia, te esfuerzas por mantener la compatibilidad con el pasado, asegurándote de que los elementos antiguos permanecen e introduciendo al mismo tiempo nuevos giros para mantener la emoción.
Por el camino, no tienes miedo de experimentar. Pones a prueba nuevas ideas, ves lo que funciona y descartas lo que no. Se trata de aprender y crecer, y cada experimento te acerca más a la solución perfecta.
En esta narrativa, metodologías como Ágil y programación extrema son sus fieles compañeras, que le guiarán por los vericuetos del desarrollo. Proporcionan estructura y apoyo, ayudándote a navegar con confianza por el cambiante panorama de las integraciones bancarias.
Y así, armado de sencillez, adaptabilidad y voluntad de aprender, tu viaje continúa. Cada capítulo conlleva nuevos retos, pero con cada reto surge la oportunidad de evolucionar y mejorar. Y al final, tu solución es un testimonio del poder de la narración en el desarrollo de software.
En la Generación 0 de nuestro enfoque de almacenamiento y recuperación de datos, adoptamos una estrategia simplista y optimista que dependía en gran medida de las API bancarias externas y de la infraestructura de red. Denominada "todo o nada", partía de la base de que cualquier fallo durante la recepción de transacciones de una cuenta significaba que los datos no se almacenarían.
Aunque implementamos un mecanismo de reintento, a menudo se quedaba corto, perpetuando el mismo bucle y dando lugar a errores persistentes como desajustes en el tipo de datos, que en última instancia impedían el almacenamiento de los datos. A pesar de sus defectos, optamos por almacenar los datos tal cual en una base de datos relacional, una decisión que, aunque poco convencional, consiguió satisfacer los requisitos iniciales de nuestro caso de uso.
Sin embargo, al profundizar en la explotación de la Generación 0, descubrimos fallos críticos en nuestra confianza excesivamente optimista en factores externos. Uno de los posibles problemas detectados es la falta de datos tras la autorización, lo que pone de manifiesto las limitaciones de un planteamiento de "todo o nada ". Se hizo evidente que necesitábamos un enfoque más resistente y adaptable de cara al futuro.
Entramos en la Generación 1. Al darnos cuenta de lo inadecuado de nuestra estrategia anterior, viramos hacia una mentalidad de "tanto como sea posible". Dado que las cuentas se gestionan bajo una autorización, refinamos nuestro enfoque para procesar cada cuenta individualmente dentro de este marco. Este método garantizaba que un problema con una cuenta concreta no interrumpiera el procesamiento de otras cuentas bajo la misma autorización. Al aislar las cuentas de esta manera, podíamos abordar y rectificar eficazmente los problemas caso por caso, mejorando nuestra capacidad para gestionar y resolver las discrepancias de manera eficiente. Este ajuste estratégico no sólo agilizó nuestra gestión de grandes volúmenes de datos, sino que también reforzó la integridad y privacidad de los datos de nuestros clientes, demostrando nuestro compromiso de mantener límites distintos entre cada cuenta, incluso dentro de un entorno de autorización unificado.
Cuando entramos en un periodo relativamente tranquilo centrado en incorporar el mayor número posible de bancos a nuestro sistema, la afluencia de tráfico arrojó luz sobre la verdadera naturaleza de nuestros datos: su forma, volumen y tamaño. Nuestra estrategia inicial de almacenar directamente los datos en su forma original empezó a sobrecargar nuestros recursos y a ralentizar nuestra capacidad de procesamiento, lo que se hizo especialmente patente al generar informes para cuentas con más de 100.000 transacciones. Ante tales volúmenes, nos hemos replanteado nuestra estrategia de almacenamiento de datos. Para solucionarlo, estamos cambiando a un método más eficiente que nos permite gestionar y generar informes sin profundizar en los detalles de las transacciones individuales. Esta estrategia revisada está diseñada para optimizar el uso de los recursos y mejorar la velocidad de procesamiento, manteniendo al mismo tiempo la confidencialidad e integridad de los datos.
Tras considerarlo detenidamente, tomamos la decisión de aprovechar todas las posibilidades de nuestra base de datos relacional. Con un conocimiento más profundo de los datos y del Modelo de datos canónico comentado en un artículo anteriornos dispusimos a crear una tabla amplia que sirviera como solución principal de almacenamiento de datos. Este cambio no sólo permitió una recuperación más eficiente de los datos, sino que también hizo necesaria la implementación del adaptador Adaptador para integrarlo perfectamente con nuestros sistemas existentes.
Sin embargo, esta transición también trajo consigo nuevos retos, sobre todo en los procesos de migración y despliegue de datos. Es posible que estas complejidades merezcan un análisis más profundo en futuras publicaciones, ya que representan aspectos significativos de nuestro viaje evolutivo.
Con el lanzamiento de la Generación 2, iniciamos una nueva era en la gestión de datos, aprovechando la potencia de las bases de datos relacionales y adoptando un enfoque más estructurado del almacenamiento. Sin embargo, nuestro viaje continúa mientras navegamos por el cambiante panorama de las integraciones bancarias, tratando de optimizar y perfeccionar nuestros procesos con cada nueva generación.
Nunca se insistirá lo suficiente en la importancia de seleccionar los tipos de datos y la capacidad adecuados, como aprendimos en un caso especialmente interesante. Inicialmente, preveíamos que nuestro sistema no se encontraría con transacciones de varios miles de millones, por lo que optamos por un tipo de datos decimal con una capacidad de 12 dígitos, incluidos 2 decimales. Sin embargo, el destino quiso que nos encontráramos con un escenario en el que esta capacidad resultó insuficiente.
El hecho de encontrarnos con transacciones que superaban nuestras expectativas iniciales nos impulsó a ampliar la capacidad de nuestro tipo de datos añadiendo otros 2 dígitos. Pero nuestro viaje no terminó ahí. Con la integración de nuestro primer proveedor de criptomonedas, nos enfrentamos a otro reto. Las transacciones de criptomonedas, con sus requisitos de escala y precisión inherentemente diferentes, requerían un ajuste adicional. Nos vimos obligados a aumentar la precisión a 8 dígitos para dar cabida a las características únicas de las transacciones criptográficas.
Esta experiencia puso de relieve la naturaleza dinámica de nuestro panorama de datos y la necesidad de mantenernos adaptables ante la evolución de los requisitos. También puso de relieve la importancia de la previsión a la hora de seleccionar los tipos de datos y la capacidad, garantizando que nuestros sistemas estén equipados para gestionar una amplia gama de volúmenes y tipos de transacciones.
A medida que ampliamos nuestra oferta de productos para incluir Verified Analytics e Insights, nuestra confianza en la fiabilidad de las bases de datos relacionales se mantuvo firme.
Sin embargo, nuestro optimismo no tardó en toparse con la realidad.
A medida que nos adentrábamos en el proceso de desarrollo, nos encontramos con un obstáculo importante: la sobrecarga del cálculo previo de los informes durante el tiempo de ejecución. Esta sobrecarga era especialmente pronunciada cuando se trataba de grandes cuentas, lo que nos llevó a replantearnos nuestro enfoque.
En respuesta, implementamos una mejora significativa en la siguiente generación de nuestro sistema. Introdujimos un concepto que acuñamos como "postprocesamiento", según el cual el cálculo de los informes se trasladaba a una fase posterior, aliviando la carga de las operaciones en tiempo de ejecución.
Este cambio estratégico no sólo agilizó nuestros procesos, sino que también mejoró la eficiencia y la escalabilidad de nuestro sistema, garantizando que nuestros productos pudieran ofrecer información puntual y precisa sin comprometer el rendimiento. Fue un momento crucial en nuestra evolución, que puso de relieve la importancia de la adaptabilidad y la mejora continua para sortear las complejidades de la gestión y el análisis de datos.
El encuentro con nuestra primera cuenta de transacciones multimillonarias planteó varios retos que provocaron una evolución significativa en nuestro enfoque de recuperación de datos. Al principio, el proceso de recopilación de datos de cuentas tan grandes llevaba mucho tiempo, a menudo varias horas. Además, el método de almacenamiento que utilizábamos no podía gestionar con eficacia la inserción de cantidades tan grandes de datos.
En medio de estos desafíos, cabe señalar que nuestros protocolos de cifrado se mantuvieron firmes, garantizando la seguridad de los datos dentro de nuestro sistema.
Para resolver estos problemas, nos embarcamos en la siguiente generación de recuperación de datos, marcada por la introducción de las inserciones bancarias. Esta innovación mejoró drásticamente el rendimiento, reduciendo los tiempos de recogida de datos dedecenas de minutos a meros segundos o unos pocos minutos.
Además, emprendimos un amplio replanteamiento y rediseño de nuestra estrategia de recuperación de datos. Una mejora clave consistió en dividir los datos históricos en trozos manejables y rellenarlos simultáneamente. Esta estrategia de paralelización aumentó considerablemente el rendimiento, multiplicando la eficiencia por N, donde N representa el número de trozos de datos.
Estos avances no sólo abordaron los retos inmediatos que planteaban las cuentas con transacciones multimillonarias, sino que también sentaron las bases de un sistema de recuperación de datos más escalable y resistente. Aprovechando las técnicas de procesamiento en paralelo y optimizando nuestro enfoque del almacenamiento y la recuperación de datos, nos aseguramos de que nuestro sistema pudiera gestionar sin problemas volúmenes de datos cada vez mayores, manteniendo al mismo tiempo unos niveles de rendimiento óptimos.
Justo cuando pensábamos que habíamos alcanzado la cima de nuestra solución de recuperación de datos, nos encontramos con una nueva serie de retos. A pesar del aumento de eficiencia que logramos con nuestro sistema de última generación, pronto nos percatamos de una tendencia alarmante: el tamaño y la carga de nuestra base de datos crecían a un ritmo sin precedentes, aparentemente desproporcionado con respecto a nuestras expectativas.
A medida que profundizábamos en las causas de este crecimiento exponencial, descubrimos una miríada de nuevos casos de uso y requisitos que surgían de diversos sectores de nuestra organización. Empezó a surgir la necesidad de funciones como el back-fill y muchas otras, lo que nos obligó a replantearnos y rediseñar nuestro enfoque una vez más.
Pero esta constatación no nos desanimó, sino que nos infundió una nueva sensación de entusiasmo y determinación. Sabíamos que el viaje hacia nuestra próxima generación de recuperación de datos estaría plagado de retos, pero también encerraba la promesa de la innovación y el progreso. Y así, con gran expectación, nos dispusimos a explorar y crear el siguiente capítulo de nuestra historia evolutiva.
Pero eso, amigo mío, es una historia para otro momento, que encontrarás ante tus ojos en las páginas de nuestras próximas aventuras.
Permanezca atento, porque lo mejor está aún por llegar.
