Construire une solution bancaire numérique évolutive fournissant un contenu personnalisé et engageant à des millions de clients soulève de nombreux défis techniques. Lisez la suite pour voir comment nous abordons ces problèmes avec la pile technologique bancaire numérique moderne de la solution Moneythor.
—
Chez Moneythor, nous concevons, développons et redéfinissons continuellement notre plateforme bancaire numérique pour répondre aux besoins des institutions financières du monde entier. Notre solution est un moteur d'orchestration et des services entièrement configurables qui se situent entre les sources de données et les canaux bancaires numériques destinés aux clients pour offrir des expériences hautement personnalisées et engageantes en temps réel.
Notre mission n'est pas seulement de construire une solution robuste, mais également d'investir dans la recherche et le développement et d'aller au-delà des limites des architectures traditionnelles pour mieux évoluer et répondre à de nouveaux cas d'utilisation difficiles comme le traitement et l'analyse d'une grande quantité de données en temps réel. .
Chaque solution présente ses propres avantages et inconvénients, d'autant plus que nous exécutons souvent des systèmes sur des réseaux et des disques existants et que nous gardons sous contrôle les coûts du processeur et de la mémoire. Sans remonter jusqu'à l'époque d'Alan Turing, les caractéristiques des problèmes traités par la solution Moneythor ont depuis longtemps été classées en deux catégories distinctes, le traitement des transactions en ligne (OLTP) et traitement analytique en ligne (OLAP).
OLTP
La solution Moneythor propose un moteur déployé entre les systèmes d'enregistrement des institutions financières et leurs canaux numériques pour proposer des expériences engageantes et personnalisées pour les utilisateurs finaux. Il est donc attendu que notre solution puisse digérer un grand volume de données en temps réel de manière fiable et évolutive.
Les systèmes de gestion de bases de données relationnelles (SGBDR) se sont historiquement révélés être un moyen efficace et fiable de mettre en œuvre un tel système OLTP, car ils offrent également l'avantage extrêmement précieux d'être conformes à l'ACID.
Notre solution comprend également Gestion de finances personnelles (PFM) des fonctionnalités pilotées par des API qui peuvent créer, lire, mettre à jour et supprimer des objets personnalisés tels que des budgets, des objectifs, des abonnements et bien plus encore. Il est donc crucial que les canaux digitaux appelant notre API puissent s'appuyer inconditionnellement sur leurs réponses et pour cela, notre solution tire largement parti de la Atomicité, Cohérence, Isolement et Durabilité (ACID) de la base de données, qu'il s'agisse d'un SGBDR ou non.
- Atomicité garantit que toutes les modifications demandées par un appel API sont réalisées avec succès dans leur ensemble. Autrement dit, lorsque notre réponse est réussie, on peut être sûr que toutes les modifications demandées ont été traitées ou aucune lorsque la réponse n'est pas réussie. Appeler une API pour créer 3 budgets créera 0 ou 3 budgets mais jamais seulement 1 ou 2.
- Cohérence préserve la cohérence interne de la base de données. Aucun appel d'API, même s'il est annulé, ne laissera jamais la base de données dans un état indésirable. L'appel d'une API pour supprimer un objectif supprimera toujours non seulement l'objectif lui-même, mais également ses dépendances.
- Isolement garantit que l'on peut appeler plusieurs API simultanées en même temps et que le résultat sera le même que si les appels étaient traités un par un. Lors de l’appel d’une API pour créer un budget et en même temps d’une API pour modifier un objectif, les deux seront traitées en tenant compte de tous ces changements. Tous les SGBDR utilisent une sorte de mécanisme de verrouillage à cette fin et il convient de mentionner que Moneythor a choisi une approche de verrouillage optimiste pour éviter tout blocage de base de données.
- Durabilité garantit qu'après qu'une API ait renvoyé une réponse positive, aucune donnée ne sera perdue en cas d'échec. Avec l'API sur HTTP, un problème courant survient en cas de panne de réseau lorsque le client ne reçoit jamais de réponse. Pour cette raison, Moneythor implémente idempotence pour aider les clients à réessayer sans risquer de créer des doublons.
OLAP
La solution Moneythor permet de fournir des informations, des recommandations et des coups de pouce basés sur les données et adaptés à chaque client. C’est là que la partie analytique de la solution brille et permet à nos clients d’imaginer une large gamme de nudges contextuels et personnalisés pour leurs clients.
Une telle analyse de données repose généralement sur un système OLAP optimisé pour cette tâche et c'est là que des frictions peuvent apparaître lorsque l'on tente de créer une solution au-dessus d'OLTP et d'OLAP.
Tout en étant intelligents dans ce qu'ils peuvent faire avec les données, les systèmes OLAP fonctionnent bien lorsque les données ne changent pas beaucoup, ce qui n'est pas un scénario typique avec une solution bancaire numérique qui reçoit des millions de transactions par jour, en temps réel et lorsque les données l’analyse devrait avoir lieu à ce moment-là. De plus, les données peuvent être modifiées par les utilisateurs eux-mêmes, ce qui peut conduire à un résultat complètement différent en matière de nudges personnalisés.
Les systèmes OLAP ne sont pas nécessairement conçus avec un temps de réponse rapide comme priorité absolue, alors que les nouvelles expériences utilisateur construites sur l'API Moneythor sont servies via HTTP et donc synchrones. Attendre plus de quelques secondes pour qu’un écran soit rendu semble aujourd’hui une éternité.
Systèmes distribués
Compte tenu de ces contraintes, la solution Moneythor exploite le meilleur des deux types de systèmes et atténue leurs lacunes grâce à une architecture distribuée présentant les caractéristiques ci-dessous.
je) Lorsque les avantages dépassent largement le coût de la redondance et du traitement supplémentaire, les données du magasin persistant sont dénormalisées au cas par cas. Cela nous permet de continuer à traiter les données transactionnelles tout en maîtrisant le temps de traitement analytique.
ii) La solution Moneythor se situe entre d'autres systèmes et s'intègre nativement aux plateformes de streaming d'événements distribués. Par exemple, Apache Kafka est un outil très populaire et, associé à la solution Moneythor, il améliore considérablement les performances globales et simplifie la mise en œuvre et l'évolutivité, car les deux systèmes sont distribués par conception. Alors que les API s'appuient fortement sur les propriétés ACID présentées ci-dessus et garantissent une réponse, lorsqu'il s'agit d'un flux de messages, Kafka et d'autres proposent généralement 3 modes de livraison de message différents : un message peut être livré ou non, un message peut être livré plusieurs fois. fois, ou un message est délivré exactement une fois. Le premier mode est évidemment interdit lorsqu’il s’agit de transactions financières, et même s’il peut être intéressant de rechercher une livraison « exactement une fois », cela entraîne un coût supplémentaire en termes de performances et de complexité. Pour cette raison et parce que les messages dans Moneythor sont idempotents, notre solution est construite autour d'un concept de livraison « au moins un » qui garantit qu'aucun message ne sera perdu, et les consommateurs peuvent simplement contrôler les doublons grâce aux drapeaux idempotents.
ii) Enfin, nous ne pouvons pas discuter des systèmes distribués sans prêter attention aux CASQUETTE et PACELC théorèmes. La première stipule que tout magasin de données distribué ne peut fournir que deux des trois garanties suivantes :
Cohérence (C) : chaque lecture, chaque appel API dans le contexte présent, reçoit la version la plus récente des données ou une erreur.
Disponibilité (A) : chaque requête API reçoit une réponse (sans erreur), sans garantie qu'elle contienne les données les plus récentes.
Tolérance de partition (P) : le système continue de fonctionner malgré un nombre arbitraire de messages abandonnés (ou retardés) par le réseau entre les nœuds.
Dans la plupart des cas, la solution Moneythor est déployée dans un environnement où il n'y a qu'une seule instance logique de la base de données (ce système de base de données fonctionnant généralement dans un cluster pour une haute disponibilité). Le nombre de partitions dans ce contexte est de 1 mais ce serait une erreur d'imaginer que le système puisse donc assurer à la fois cohérence et disponibilité. En effet, en l'absence de partitionnement, le théorème PACELC affine ces règles en affirmant qu'il faut choisir entre Latence (Atterrir Cohérence (C).
La solution Moneythor est conçue pour évoluer verticalement en ajoutant de la puissance de traitement et horizontalement en ajoutant des instances supplémentaires dans son cluster. Il expose également un ensemble d'API frontales utilisées pour offrir des fonctionnalités interactives riches aux utilisateurs finaux avec le temps de réponse minimum possible pour une expérience utilisateur optimale.
Pour ces raisons, la solution est optimisée pour la latence. Bien que ce choix puisse paraître contre-intuitif surtout après avoir affirmé que les API s'appuient sur le modèle ACID, la définition de la cohérence est ici différente et ne s'applique pas aux données manipulées et calculées par une API qui doit être cohérente quoi qu'il arrive mais déterminer quand le plus de temps est disponible. les données seront disponibles, immédiatement ou éventuellement.
Au contraire, cibler d'abord la cohérence signifierait également que le système devrait attendre que de nombreuses instances du cluster soient synchronisées avant de renvoyer une réponse, car la solution utilise des caches en mémoire pour accélérer le traitement et les temps de réponse des API. Malgré le meilleur réseau et le meilleur processeur de sa catégorie, il serait extrêmement difficile de garantir des temps de réponse de premier ordre dans ce cas.
Essentiellement, il existe des principes simples qui peuvent être mis en œuvre pour réduire considérablement le risque de lecture de données désynchronisées. Un équilibreur de charge correctement configuré acheminant les requêtes dans le cluster vers la même instance où les données du contexte actuel ont déjà été traitées et mises en cache auparavant en est un exemple.
Conclusion
Construire une solution hautement évolutive et en temps réel combinant des données transactionnelles et analytiques est un compromis entre les fonctionnalités qui peuvent être fournies, les temps de réponse attendus et bien sûr le coût de déploiement et d'exploitation d'un tel système.
Les architectures distribuées et décentralisées peuvent être complexes à construire, et il est nécessaire de comprendre leurs caractéristiques pour tenir leurs promesses. Parallèlement, la technologie évolue et le calcul haute performance est de plus en plus accessible, notamment avec les plateformes Cloud. Ce sont les raisons pour lesquelles nous avons choisi de prendre cette direction, qui nous permet désormais de répondre avec succès aux besoins de personnalisation basée sur les données des banques numériques et des institutions financières de toutes tailles.
Pour en savoir plus sur la solution Moneythor et notre technologie, veuillez Contactez-nous.
