Je suis sûr que vous l'avez vu venir, "Ça dépend".
Cela dépend de tout. Et la solution de partage des données client pour le service A peut être complètement différente pour le partage des données client avec le service B.
Mon concept préféré qui s'est imposé au fil des ans est le concept de "cohérence éventuelle". Le terme vient d'Amazon parlant de systèmes distribués.
Le principe est que même si l'état des données dans une entreprise distribuée n'est peut-être pas parfaitement cohérent actuellement, il le sera "éventuellement".
Par exemple, lorsqu'un enregistrement client est mis à jour sur le système A, les données client du système B sont désormais obsolètes et ne correspondent pas. Mais, "éventuellement", l'enregistrement de A sera envoyé à B via un processus. Donc, finalement, les deux instances correspondront.
Lorsque vous travaillez avec un seul système, vous n'avez pas "EC", mais plutôt des mises à jour instantanées, une seule "source de vérité" et, généralement, un mécanisme de verrouillage pour gérer les conditions de concurrence et les conflits.
Plus vos opérations sont capables de travailler avec des données "EC", plus il est facile de séparer ces systèmes. Un exemple simple est un entrepôt de données utilisé par les ventes. Ils utilisent le DW pour exécuter leurs rapports quotidiens, mais ils n'exécutent leurs rapports qu'au petit matin et ils consultent toujours les données "d'hier" (ou antérieures). Il n'est donc pas nécessaire que le DW soit parfaitement cohérent avec le système d'exploitation quotidien. Il est parfaitement acceptable qu'un processus s'exécute, par exemple, à la fermeture des bureaux et se déplace au fil des jours des transactions et des activités en masse dans une grande opération de mise à jour unique.
Vous pouvez voir comment cette exigence peut résoudre de nombreux problèmes. Il n'y a pas de conflit pour les données transactionnelles, pas de souci que certaines données de rapports changent au milieu de l'accumulation de la statistique car le rapport a effectué deux requêtes distinctes dans la base de données en direct. Pas besoin que le bavardage très détaillé aspire le traitement du réseau et du processeur, etc. pendant la journée.
Maintenant, c'est un exemple extrême, simplifié et très grossier d'EC.
Mais considérez un grand système comme Google. En tant que consommateur de la recherche, nous n'avons aucune idée du moment ou du temps qu'il faut pour qu'un résultat de recherche que Google récolte arrive sur une page de recherche. 1 ms ? 1s ? 10 s ? 10h ? Il est facile d'imaginer que si vous accédez aux serveurs de la côte ouest de Google, vous pouvez très bien obtenir un résultat de recherche différent de celui obtenu si vous accédez à leurs serveurs de la côte est. À aucun moment, ces deux instances ne sont complètement cohérentes. Mais dans une large mesure, ils sont pour la plupart cohérents. Et pour leur cas d'utilisation, leurs consommateurs ne sont pas vraiment affectés par le décalage et le retard.
Pensez au courrier électronique. A veut envoyer un message à B, mais dans le processus, le message est acheminé via les systèmes C, D et E. Chaque système accepte le message, en assume l'entière responsabilité, puis le transmet à un autre. L'expéditeur voit l'email continuer son chemin. Le récepteur ne le rate pas vraiment car il ne sait pas nécessairement ce qu'il vient. Il y a donc une grande fenêtre de temps que cela peut prendre pour que ce message se déplace dans le système sans que personne concerné ne sache ou ne se soucie de sa rapidité.
D'un autre côté, A aurait pu être au téléphone avec B. "Je viens de l'envoyer, l'avez-vous déjà reçu ? Maintenant ? Maintenant ? Recevez-le maintenant ?"
Ainsi, il existe une sorte de niveau sous-jacent et implicite de performance et de réponse. En fin de compte, "éventuellement", la boîte d'envoi de A correspond à la boîte de réception de B.
Ces retards, l'acceptation de données obsolètes, qu'elles datent d'un jour ou de 1 à 5 secondes, sont ce qui contrôle le couplage ultime de vos systèmes. Plus cette exigence est faible, plus le couplage est faible et plus vous disposez de flexibilité en termes de conception.
Cela est vrai jusqu'aux cœurs de votre CPU. Les applications modernes, multi-cœurs et multi-thread exécutées sur le même système peuvent avoir différentes vues des "mêmes" données, obsolètes à seulement quelques microsecondes. Si votre code peut fonctionner correctement avec des données potentiellement incohérentes les unes avec les autres, alors bonne journée, il s'enchaîne. Si ce n'est pas le cas, vous devez porter une attention particulière à la cohérence totale de vos données, en utilisant des techniques telles que la qualification de la mémoire volatile ou le verrouillage des constructions, etc. Tout cela, à sa manière, nuit à la performance.
Donc, c'est la considération de base. Toutes les autres décisions commencent ici. Répondre à cela peut vous dire comment partitionner les applications sur les machines, quelles ressources sont partagées et comment elles sont partagées. Quels protocoles et techniques sont disponibles pour déplacer les données, et combien cela coûtera en termes de traitement pour effectuer le transfert. Réplication, équilibrage de charge, partages de données, etc. etc. Tous basés sur ce concept.
Edit, en réponse au premier commentaire.
Correct, exactement. Le jeu ici, par exemple, si B ne peut pas modifier les données client, alors quel est le mal avec les données client modifiées ? Pouvez-vous "risquer" qu'il soit obsolète pendant une courte période ? Peut-être que vos données client arrivent assez lentement pour que vous puissiez les répliquer immédiatement de A à B. Supposons que la modification est placée dans une file d'attente qui, en raison d'un faible volume, est récupérée facilement (<1 s), mais même quand même, elle serait "hors transaction" avec la modification d'origine, et il y a donc une petite fenêtre où A aurait données que B n'a pas.
Maintenant, l'esprit commence vraiment à tourner. Que se passe-t-il pendant ces 1 secondes de "décalage", quel est le pire scénario possible. Et pouvez-vous concevoir autour de cela? Si vous pouvez concevoir un décalage d'environ 1 s, vous pourrez peut-être concevoir un décalage d'environ 5 s, 1 m ou même plus. Quelle quantité de données client utilisez-vous réellement sur B ? Peut-être que B est un système conçu pour faciliter la préparation des commandes à partir de l'inventaire. Difficile d'imaginer que quelque chose de plus soit nécessaire qu'un simple identifiant client et peut-être un nom. Juste quelque chose pour identifier grossièrement à qui la commande est destinée pendant son assemblage.
Le système de prélèvement n'a pas nécessairement besoin d'imprimer toutes les informations client jusqu'à la toute fin du processus de prélèvement, et à ce moment-là, la commande peut être passée à un autre système qui est peut-être plus à jour avec, en particulier, les informations d'expédition, donc au final, le système de préparation de commandes n'a pratiquement pas besoin de données client. En fait, vous pouvez INTÉGRER et dénormaliser les informations client dans la commande de prélèvement, de sorte qu'il n'y a pas besoin ni attente de synchronisation ultérieure. Tant que l'ID client est correct (qui ne changera jamais de toute façon) et le nom (qui change si rarement que cela ne vaut pas la peine d'en discuter), c'est la seule véritable référence dont vous avez besoin, et tous vos bordereaux de prélèvement sont parfaitement exacts au moment de création.
L'astuce est l'état d'esprit, consistant à décomposer les systèmes et à se concentrer sur les données essentielles nécessaires à la tâche. Les données dont vous n'avez pas besoin n'ont pas besoin d'être répliquées ou synchronisées. Les gens s'irritent de choses comme la dénormalisation et la réduction des données, surtout lorsqu'ils viennent du monde de la modélisation des données relationnelles. Et pour cause, elle doit être considérée avec prudence. Mais une fois que vous êtes distribué, vous avez implicitement dénormalisé. Heck, vous le copiez en gros maintenant. Donc, autant être plus intelligent à ce sujet.
Tout cela peut être atténué par des procédures solides et une compréhension approfondie du flux de travail. Identifiez les risques et élaborez une politique et des procédures pour les gérer.
Mais le plus difficile est de briser la chaîne vers la base de données centrale au début et d'informer les gens qu'ils ne peuvent pas "tout avoir" comme ils peuvent s'y attendre lorsque vous disposez d'un stockage d'informations unique, central et parfait.
