La creación de una solución de banca digital escalable que ofrezca contenido atractivo y personalizado a millones de clientes plantea múltiples desafíos técnicos. Continúe leyendo para ver cómo los abordamos con la moderna tecnología de banca digital de la solución Moneythor.
—
En Moneythor, continuamente diseñamos, desarrollamos y redefinimos nuestra plataforma de banca digital para satisfacer las necesidades de las instituciones financieras a nivel mundial. Nuestra solución es un motor de orquestación y servicios totalmente configurables que se ubican entre las fuentes de datos y los canales de banca digital de cara al cliente para ofrecer experiencias altamente personalizadas y atractivas en tiempo real.
Nuestra misión no es solo construir una solución sólida, sino también invertir en investigación y desarrollo e ir más allá de los límites de las arquitecturas tradicionales para escalar mejor y abordar nuevos casos de uso desafiantes, como procesar y analizar una gran cantidad de datos en tiempo real. .
Cada solución tiene sus propias ventajas e inconvenientes, especialmente teniendo en cuenta que a menudo ejecutamos sistemas en redes y discos heredados y mantenemos bajo control los costos de CPU y memoria. Sin remontarnos a la era de Alan Turing, las características de los problemas que aborda la solución Moneythor se han clasificado desde hace mucho tiempo en dos categorías distintas: procesamiento de transacciones en línea (OLTP) y procesamiento analítico en línea (OLAP).
OLTP
La solución Moneythor ofrece un motor implementado entre los sistemas de registro de las instituciones financieras y sus canales digitales para impulsar experiencias atractivas y personalizadas para los usuarios finales. Por lo tanto, se espera que nuestra solución pueda digerir un gran volumen de datos en tiempo real de forma confiable y escalable.
Históricamente, se ha demostrado que los sistemas de gestión de bases de datos relacionales (RDBMS) son una forma eficiente y confiable de implementar dicho sistema OLTP, ya que también ofrecen el beneficio extremadamente valioso de ser compatibles con ACID.
Nuestra solución también incluye Gestión de finanzas personales (PFM) funciones impulsadas por API que pueden crear, leer, actualizar y eliminar objetos personalizados como presupuestos, objetivos, suscripciones y más. Por lo tanto, es crucial que los canales digitales que llaman a nuestra API puedan confiar incondicionalmente en sus respuestas y, para ello, nuestra solución aprovecha en gran medida la Atomicidad, Consistencia, Aislamiento y Durabilidad (ACID) propiedades de la base de datos, ya sea un RDBMS o no.
- Atomicidad garantiza que todas las modificaciones solicitadas por una llamada API se completen con éxito en su conjunto. Es decir, cuando nuestra respuesta es exitosa se puede confiar en que se han procesado todas las modificaciones solicitadas o ninguna cuando la respuesta no es exitosa. Llamar a una API para crear 3 presupuestos creará 0 o 3 presupuestos, pero nunca solo 1 o 2.
- Consistencia preserva la coherencia interna de la base de datos. Ninguna llamada a la API, incluso si se cancela, dejará la base de datos en un estado no deseado. Llamar a una API para eliminar un objetivo siempre eliminará no solo el objetivo en sí sino también sus dependencias.
- Aislamiento garantiza que se puedan llamar a varias API simultáneas al mismo tiempo y el resultado será el mismo que si las llamadas se procesaran una a la vez. Al llamar a una API para crear un presupuesto y al mismo tiempo a una API para modificar una meta, ambas se procesarán teniendo en cuenta todos estos cambios. Todos los RDBMS utilizan algún tipo de mecanismo de bloqueo para ese propósito y vale la pena mencionar que Moneythor eligió un enfoque de bloqueo optimista para evitar cualquier punto muerto en la base de datos.
- Durabilidad garantiza que después de que una API devuelva una respuesta exitosa, no se perderán datos en caso de falla. Con API sobre HTTP, surge un problema común en caso de una falla de la red cuando el cliente nunca recibe una respuesta. Por esa razón, Moneythor implementa idempotencia para ayudar a los clientes a volver a intentarlo sin el riesgo de crear duplicados.
OLAP
La solución Moneythor permite la entrega de conocimientos, recomendaciones y empujones basados en datos adaptados a cada cliente. Aquí es donde brilla la parte analítica de la solución y permite a nuestros clientes imaginar una amplia gama de empujones contextuales y personalizados para sus clientes.
Este tipo de análisis de datos generalmente se basa en un sistema OLAP optimizado para esa tarea y es donde pueden surgir fricciones al intentar construir una solución sobre OLTP y OLAP.
Si bien son inteligentes con lo que pueden hacer con los datos, los sistemas OLAP funcionan bien cuando los datos no cambian mucho, lo cual no es un escenario típico con una solución de banca digital que recibe millones de transacciones al día, en tiempo real y cuando los datos Se espera que el análisis se realice en ese momento. Además, los propios usuarios pueden cambiar los datos y esto puede llevar a un resultado completamente diferente cuando se trata de empujones personalizados.
Los sistemas OLAP no están necesariamente diseñados con un tiempo de respuesta rápido como máxima prioridad, mientras que las nuevas experiencias de usuario creadas sobre la API de Moneythor se ofrecen a través de HTTP y, por lo tanto, son sincrónicas. Esperar más de unos segundos para que se renderice una pantalla hoy en día parece una eternidad.
Sistemas distribuidos
Teniendo en cuenta estas limitaciones, la solución Moneythor aprovecha lo mejor de ambos tipos de sistemas y mitiga sus deficiencias a través de una arquitectura distribuida con las características siguientes.
i) Cuando los beneficios superan con creces el costo de la redundancia y el procesamiento adicional, los datos en el almacén persistente se desnormalizan caso por caso. Esto nos permite continuar procesando datos transaccionales mientras mantenemos bajo control el tiempo de procesamiento analítico.
ii) La solución Moneythor se ubica entre otros sistemas y se integra de forma nativa con plataformas distribuidas de transmisión de eventos. Por ejemplo, Apache Kafka es una herramienta muy popular y, junto con la solución Moneythor, mejora enormemente el rendimiento general y simplifica la implementación y la escalabilidad, porque ambos sistemas están distribuidos por diseño. Si bien las API dependen en gran medida de las propiedades ACID presentadas anteriormente y garantizan una respuesta, cuando se trata de un flujo de mensajes, Kafka y otros generalmente ofrecen 3 modos diferentes de entrega de mensajes: un mensaje puede entregarse o no, un mensaje puede entregarse múltiples veces, o un mensaje se entrega exactamente una vez. El primer modo es obviamente prohibido cuando se trata de transacciones financieras, y si bien puede resultar atractivo buscar una entrega "exactamente una vez", esto conlleva un costo adicional de rendimiento y complejidad. Por esta razón y porque los mensajes en Moneythor son idempotentes, nuestra solución se basa en un concepto de entrega de "al menos un" que garantiza que no se perderá ningún mensaje y los consumidores pueden simplemente controlar los duplicados gracias a las banderas idempotentes.
ii) Finalmente, no podemos hablar de sistemas distribuidos sin prestar atención a la GORRA y PACELC teoremas El primero establece que cualquier almacén de datos distribuido sólo puede ofrecer dos de las tres garantías siguientes:
Consistencia (C): cada lectura, cada llamada API en el contexto actual, recibe la versión más reciente de los datos o un error.
Disponibilidad (A): cada solicitud de API recibe una respuesta (sin error), sin la garantía de que contenga los datos más recientes.
Tolerancia de partición (P): el sistema continúa funcionando a pesar de que la red descarta (o retrasa) un número arbitrario de mensajes entre nodos.
En la mayoría de los casos, la solución Moneythor se implementa en un entorno donde solo hay una instancia lógica de la base de datos (y este sistema de base de datos generalmente se ejecuta en un clúster para alta disponibilidad). El número de particiones en este contexto es 1, pero sería un error imaginar que el sistema podría proporcionar coherencia y disponibilidad al mismo tiempo. De hecho, en ausencia de partición, el teorema PACELC refina esas reglas al afirmar que uno debe elegir entre Latencia (Tierra Consistencia (C).
La solución Moneythor está diseñada para escalar verticalmente agregando potencia de procesamiento y horizontalmente agregando instancias adicionales en su clúster. También expone un conjunto de API de front-end que se utilizan para habilitar funciones interactivas enriquecidas para los usuarios finales con el mínimo tiempo de respuesta posible para una experiencia de usuario óptima.
Por estos motivos, la solución está optimizada para la latencia. Si bien esta elección puede parecer contradictoria, especialmente después de afirmar que las API se basan en el modelo ACID, la definición de coherencia es diferente aquí y no se aplica a los datos manipulados y calculados por una API que debe ser coherente pase lo que pase, pero determina cuándo está más arriba. a los datos estarán disponibles, inmediata o eventualmente.
Por el contrario, apuntar primero a la coherencia también significaría que el sistema tendría que esperar a que se sincronicen muchas instancias en el clúster antes de devolver una respuesta, ya que la solución utiliza cachés en memoria para acelerar el procesamiento y los tiempos de respuesta de la API. A pesar de contar con la mejor red y CPU de su clase, sería extremadamente difícil garantizar tiempos de respuesta de primera clase en ese caso.
Básicamente, existen principios simples que se pueden implementar para reducir drásticamente el riesgo de leer datos no sincronizados. Un ejemplo es un equilibrador de carga configurado correctamente que enruta las solicitudes en el clúster a la misma instancia donde los datos para el contexto actual ya se procesaron y almacenaron en caché.
Conclusión
Crear una solución altamente escalable y en tiempo real que combine datos transaccionales y analíticos es una compensación entre las características que se pueden proporcionar, cuáles son las expectativas de tiempos de respuesta y, por supuesto, el costo de implementar y operar dicho sistema.
Las arquitecturas distribuidas y descentralizadas pueden ser complejas de construir y es necesario comprender sus características para cumplir sus promesas. Al mismo tiempo, la tecnología está evolucionando y la informática de alto rendimiento es cada vez más accesible, especialmente con las plataformas en la nube. Estas son las razones por las que hemos elegido tomar esta dirección, lo que ahora nos permite satisfacer con éxito las necesidades de personalización basada en datos de los bancos digitales y las instituciones financieras de todos los tamaños.
Para obtener más información sobre la solución Moneythor y nuestra tecnología, por favor Contáctenos.
