Imaginez que vous vous lanciez dans un voyage pour vous attaquer aux complexités de l'intégration des banques dans votre système. Vous partez d'une idée simple : rassembler, stocker et présenter des données. Mais le paysage est en constante évolution et d'innombrables inconnues se cachent à chaque coin de rue.
Vous avez donc pris une décision : rester simple et se concentrer sur les besoins actuels. Votre solution doit être comme un organisme vivant, qui s'adapte constamment à son environnement. Cela s'apparente au concept des algorithmes génétiques, où les solutions évoluent au fil du temps, apprenant de leurs erreurs et s'améliorant à chaque itération.
Imaginez la situation comme suit : chaque génération de votre solution est comme un nouveau chapitre d'une histoire. Vous commencez par ce qui fonctionne, mais vous êtes toujours ouvert à de nouveaux défis et à de nouvelles expériences. Et comme dans une bonne histoire, vous vous efforcez d'assurer la compatibilité ascendante - en veillant à ce que les anciens éléments soient conservés tout en introduisant de nouveaux rebondissements pour garder les choses passionnantes.
En cours de route, vous n'avez pas peur d'expérimenter. Vous testez de nouvelles idées, voyez ce qui fonctionne et rejetez ce qui ne fonctionne pas. Il s'agit d'apprendre et de progresser, chaque expérience vous rapprochant de la solution parfaite.
Dans ce contexte, des méthodologies telles que Agile et programmation extrême sont vos compagnons de confiance et vous guident dans les méandres du développement. Elles vous apportent structure et soutien, vous aidant à naviguer en toute confiance dans le paysage en constante évolution des intégrations bancaires.
Ainsi, armé de simplicité, d'adaptabilité et d'une volonté d'apprendre, votre voyage se poursuit. Chaque chapitre apporte de nouveaux défis, mais chaque défi est l'occasion d'évoluer et de s'améliorer. Au final, votre solution témoigne du pouvoir de la narration dans le développement de logiciels.
Dans la génération 0 de notre approche du stockage et de la récupération des données, nous avons adopté une stratégie simpliste et optimiste, fortement tributaire des API bancaires externes et de l'infrastructure du réseau. Surnommée l'approche "tout ou rien", elle partait du principe que toute défaillance lors de la réception d'une transaction pour un compte signifiait que les données ne seraient pas stockées.
Bien que nous ayons mis en place un mécanisme de réessai, celui-ci s'est souvent avéré insuffisant, perpétuant la même boucle et conduisant à des erreurs persistantes telles que la non-concordance des types de données, ce qui a finalement empêché le stockage des données. Malgré ses défauts, nous avons choisi de stocker les données telles quelles dans une base de données relationnelle, une décision qui, bien que non conventionnelle, a permis de répondre aux exigences de notre cas d'utilisation initial.
Cependant, lorsque nous nous sommes penchés sur l'exploitation de la génération 0, nous avons découvert des failles critiques dans notre confiance trop optimiste dans les facteurs externes. L'un des problèmes potentiels identifiés est la question des données manquantes après l'autorisation, ce qui met en évidence les limites d'une approche "tout ou rien". Il est devenu évident que nous avions besoin d'une approche plus résiliente et plus adaptable pour aller de l'avant.
Entrez dans la Génération 1. Conscients des insuffisances de notre stratégie précédente, nous avons pivoté vers un état d'esprit "autant que possible". Étant donné que les comptes sont gérés dans le cadre d'une autorisation, nous avons affiné notre approche pour traiter chaque compte individuellement dans ce cadre. Cette méthode a permis de s'assurer qu'un problème concernant un compte spécifique n'interrompait pas le traitement d'autres comptes relevant de la même autorisation. En isolant les comptes de cette manière, nous avons pu traiter et rectifier efficacement les problèmes au cas par cas, améliorant ainsi notre capacité à gérer et à résoudre les divergences de manière efficace. Cet ajustement stratégique a non seulement rationalisé notre traitement de gros volumes de données, mais a également renforcé l'intégrité et la confidentialité des données de nos clients, démontrant ainsi notre engagement à maintenir des frontières distinctes entre chaque compte, même dans un environnement d'autorisation unifié.
Alors que nous entrions dans une période relativement calme, axée sur l'intégration du plus grand nombre possible de banques dans notre système, l'afflux de trafic a mis en lumière la véritable nature de nos données - leur forme, leur volume et leur taille. Notre stratégie initiale consistant à stocker directement les données dans leur forme originale a commencé à peser sur nos ressources et à ralentir nos capacités de traitement, ce qui était particulièrement visible lors de la génération de rapports pour des comptes comportant plus de 100 000 transactions. La rencontre de tels volumes nous a incités à réévaluer notre approche du stockage des données. Pour y remédier, nous avons opté pour une méthode plus efficace qui nous permet de gérer et de générer des rapports sans entrer dans les détails des transactions individuelles. Cette stratégie révisée est conçue pour optimiser l'utilisation des ressources et améliorer la vitesse de traitement tout en préservant la confidentialité et l'intégrité des données.
Après mûre réflexion, nous avons décidé d'exploiter toutes les capacités de notre base de données relationnelle. Armés d'une compréhension plus approfondie des données et du modèle de données Canonic discuté dans un article précédentnous avons entrepris de créer une table large pour servir de solution de stockage primaire des données. Ce changement n'a pas seulement permis une récupération plus efficace des données, mais a également nécessité l'implémentation de l'adaptateur adaptateur afin de s'intégrer de manière transparente à nos systèmes existants.
Toutefois, cette transition a également entraîné de nouveaux défis, notamment en ce qui concerne la migration des données et les processus de déploiement. Ces complexités méritent d'être explorées plus avant dans de futures publications, car elles représentent des aspects importants de notre évolution.
Avec la sortie de la Génération 2, nous avons inauguré une nouvelle ère de gestion des données, en exploitant la puissance des bases de données relationnelles et en adoptant une approche plus structurée du stockage. Cependant, notre voyage se poursuit alors que nous naviguons dans le paysage en constante évolution des intégrations bancaires, en cherchant à optimiser et à affiner nos processus à chaque nouvelle génération.
On ne saurait trop insister sur l'importance de choisir des types de données et des capacités appropriés, comme nous l'avons appris à l'occasion d'un cas particulièrement intéressant. Initialement, nous pensions que notre système ne rencontrerait pas de transactions de l'ordre de plusieurs milliards, et nous avons donc opté pour un type de données décimal d'une capacité de 12 chiffres, dont 2 décimales. Cependant, comme le veut le destin, nous avons rencontré un scénario dans lequel cette capacité s'est avérée insuffisante.
Le fait de rencontrer des transactions dépassant nos attentes initiales nous a incités à étendre la capacité de notre type de données en ajoutant deux chiffres supplémentaires. Mais notre aventure ne s'est pas arrêtée là. Avec l'intégration de notre premier fournisseur de crypto-monnaies, nous avons été confrontés à un autre défi. Les transactions en crypto-monnaies, avec leurs exigences intrinsèquement différentes en matière d'échelle et de précision, ont nécessité un ajustement supplémentaire. Nous nous sommes trouvés dans l'obligation d'augmenter la précision à 8 chiffres pour tenir compte des caractéristiques uniques des transactions en crypto-monnaies.
Cette expérience a mis en évidence la nature dynamique de notre paysage de données et la nécessité de rester adaptable face à l'évolution des exigences. Elle a également mis en évidence l'importance de la prévoyance dans le choix des types de données et de la capacité, en veillant à ce que nos systèmes soient équipés pour traiter une gamme variée de volumes et de types de transactions.
Alors que nous élargissions notre offre de produits pour inclure Verified Analytics et Insights, notre confiance dans la fiabilité des bases de données relationnelles est restée inébranlable.
Cependant, notre optimisme s'est rapidement heurté à la réalité.
Au fur et à mesure que nous avancions dans le processus de développement, nous nous sommes heurtés à un obstacle de taille : les frais généraux liés au pré-calcul des rapports au cours de l'exécution. Cette surcharge est devenue particulièrement prononcée lorsqu'il s'agissait de traiter des comptes importants, ce qui nous a amenés à réévaluer notre approche.
En réponse, nous avons apporté une amélioration significative à la prochaine génération de notre système. Nous avons introduit un concept que nous avons baptisé "post-traitement", selon lequel le calcul des rapports est reporté à un stade ultérieur, ce qui allège le fardeau des opérations d'exécution.
Ce changement stratégique a non seulement permis de rationaliser nos processus, mais aussi d'améliorer l'efficacité et l'évolutivité de notre système, en veillant à ce que nos produits puissent fournir des informations opportunes et précises sans compromettre les performances. Ce fut un moment charnière dans notre parcours évolutif, soulignant l'importance de l'adaptabilité et de l'amélioration continue pour naviguer dans les complexités de la gestion et de l'analyse des données.
La rencontre avec notre premier compte de plusieurs millions de transactions a posé plusieurs défis qui ont entraîné une évolution significative de notre approche de la recherche de données. Initialement, le processus de collecte des données pour des comptes aussi importants s'est avéré fastidieux, prenant souvent plusieurs heures. En outre, notre méthode de stockage existante avait du mal à gérer efficacement l'insertion de quantités de données aussi importantes.
Au milieu de ces défis, il convient de noter que nos protocoles de cryptage sont restés inébranlables, garantissant la sécurité des données au sein de notre système.
Pour résoudre ces problèmes, nous nous sommes lancés dans la nouvelle génération de recherche de données, marquée par l'introduction des insertions bancaires. Cette innovation a considérablement amélioré les performances, réduisant les temps de collecte des données de dizaines deminutes à seulement quelques secondes ou quelques minutes.
En outre, nous avons entrepris de repenser et de redéfinir notre stratégie d'extraction des données. L'une des principales améliorations a consisté à diviser les données historiques en morceaux gérables et à les remplir simultanément. Cette stratégie de parallélisation a permis d'améliorer considérablement les performances, en augmentant l'efficacité d'un facteur N, où N représente le nombre de blocs de données.
Ces avancées ont non seulement permis de relever les défis immédiats posés par les comptes à plusieurs millions de transactions, mais elles ont également jeté les bases d'un système d'extraction de données plus évolutif et plus résistant. En tirant parti des techniques de traitement parallèle et en optimisant notre approche du stockage et de la récupération des données, nous avons fait en sorte que notre système puisse traiter de manière transparente des volumes croissants de données tout en maintenant des niveaux de performance optimaux.
Alors que nous pensions avoir atteint le sommet de notre solution de recherche de données, nous nous sommes retrouvés confrontés à une nouvelle série de défis. Malgré les gains d'efficacité obtenus avec notre système de dernière génération, nous avons rapidement remarqué une tendance alarmante : la taille et la charge de notre base de données augmentaient à un rythme sans précédent, apparemment disproportionné par rapport à nos attentes.
En nous penchant sur les causes profondes de cette croissance exponentielle, nous avons découvert une myriade de nouveaux cas d'utilisation et d'exigences émanant de différents services de notre organisation. Le besoin de capacités telles que les back-fills et bien d'autres a commencé à émerger, nous obligeant à repenser et à redéfinir notre approche une fois de plus.
Mais cette prise de conscience n'a pas entamé notre enthousiasme ; au contraire, elle a fait naître en nous un nouveau sentiment d'excitation et de détermination. Nous savions que le chemin vers notre nouvelle génération de recherche de données serait semé d'embûches, mais il était aussi porteur de promesses d'innovation et de progrès. C'est donc avec impatience que nous avons entrepris d'explorer et de créer le prochain chapitre de notre histoire évolutive.
Mais cela, mon ami, est une histoire pour une autre fois - une histoire qui se déroulera sous vos yeux dans les pages de nos prochaines aventures.
Restez à l'écoute, car le meilleur reste à venir.
