L'architecture basée sur des cellules partitionne un service en instances indépendantes appelées cellules, chacune capable de gérer un sous-ensemble de trafic de manière autonome. Pour une plateforme de paiement, chaque cellule comprend une pile complète : équilibreurs de charge, serveurs d'application, bases de données et queues de messages, déployés dans plusieurs zones de disponibilité mais isolés des autres cellules aux niveaux réseau et données. Le routage du trafic repose sur un sharding déterministe utilisant des identifiants de client, garantissant qu'un seul client est mappé exclusivement à une cellule active tout en maintenant la capacité de vider et de faire pivoter les cellules sans interruption de service.
La cohérence entre les cellules pour les préoccupations transversales (par exemple, détection de fraude, rapports réglementaires) est obtenue par le biais de réplication d'événements asynchrones utilisant des flux de Change Data Capture (CDC), tandis que les transactions intra-cellules maintiennent des garanties ACID via des clusters de bases de données locaux. La rotation des cellules exploite des modèles de déploiement blue-green au sein des limites de la cellule, associés à des disjoncteurs et une orientation du trafic basée sur des vérifications de santé au niveau global de la CDN Edge pour isoler automatiquement les cellules dégradées.
Un processeur de paiement de niveau 1 gérant 15 milliards de dollars de transactions quotidiennes a connu un échec en cascade catastrophique dans son monolithe régional US-Est lorsque la corruption d'un index de base de données s'est propagée à travers les zones de disponibilité. Cela a entraîné une panne mondiale de 4 heures affectant 40 millions de clients et violant les exigences de disponibilité de PCI DSS. Le retour d'expérience a révélé que des composants d'infrastructure partagés avaient créé des dépendances de défaillance cachées, violant le principe des domaines de défaillance indépendants requis pour une haute disponibilité dans les systèmes financiers.
Solution A : Réplication Multi-Régionale Active-Active
Cette approche déploierait des piles identiques dans plusieurs régions avec une réplication de base de données multi-maître utilisant Galera Cluster ou CockroachDB, permettant des écritures dans n'importe quelle région. L'avantage principal est l'utilisation complète des ressources et la localité géographique pour la réduction de latence. Cependant, la complexité de la résolution des conflits pour les transactions financières introduit des risques inacceptables de double dépense ou d'états de solde incohérents lors des partitions réseau, tandis que la charge opérationnelle de gestion des horloges vectorielles et des conflits de fusion augmente de manière exponentielle avec le volume des transactions.
Solution B : Actif-Passif avec Veille Chaude
La mise en œuvre d'une architecture de veille chaude maintient une région secondaire en synchronisation constante via une réplication synchrone, prête à assumer le trafic en quelques secondes après un échec primaire. Cela garantit une forte cohérence et élimine les scénarios de double cerveau grâce à une orchestration explicite de basculement. L'inconvénient critique est le gaspillage de 50 % des ressources pendant les opérations normales, et l'incapacité à effectuer des rotations ou des mises à jour progressives sans événements de basculement complet, compliquant les fenêtres de maintenance de routine et augmentant le risque de déploiement.
Solution C : Partitionnement par Cellules avec Routage Déterministe
L'architecture sélectionnée partitionne la base de clients en 20 cellules distinctes, chacune gérant 5 % du trafic mondial avec des clusters Kubernetes isolés, des PostgreSQL principaux dédiés et des brokers Kafka indépendants. Les sidecars Envoy Proxy mettent en œuvre un hachage cohérent sur customer_id pour acheminer les requêtes vers des cellules spécifiques, tandis qu'un plan de contrôle global surveille la santé des cellules et orchestre l'évacuation du trafic lors des rotations. Cela limite la zone d'impact à 5 % des utilisateurs lors des pannes au niveau des cellules et permet des rotations sans temps d'arrêt en déplaçant progressivement le trafic vers de nouvelles générations de cellules en utilisant l'analyse de canard et des déclencheurs de retour automatique.
Suite à la mise en œuvre, la plateforme a atteint une disponibilité de 99,999 % (moins de 5 minutes de temps d'arrêt par an), a réduit la zone d'impact des incidents de 95 % et a diminué le risque de déploiement grâce à des déploiements canary au niveau des cellules qui validaient les changements par rapport à des sous-ensembles de trafic de production avant un déploiement global.
Comment maintenez-vous l'intégrité référentielle pour les entités qui s'étendent sur plusieurs cellules, telles que les comptes d'entreprise avec des sous-comptes répartis sur différentes cellules ?
Les candidats supposent souvent à tort que l'isolement strict des cellules empêche toute transaction intercellulaire. La solution met en œuvre un modèle Saga avec des transactions compensatoires orchestrées par un moteur de workflow léger Temporal ou Camunda fonctionnant dans un plan de contrôle séparé. Pour les opérations intercellules, le système utilise un engagement en deux phases (2PC) uniquement pour la phase de coordination, tandis que les mutations réelles restent locales à la cellule. Les clés d'idempotence garantissent que les échecs partiels pendant les opérations distribuées peuvent être réessayés en toute sécurité sans duplication des impacts financiers. De plus, les vues matérialisées dans un cache en lecture seule global fournissent des requêtes intercellulaires éventuellement cohérentes sans violer les limites d'isolement.
Comment géreriez-vous la conformité en matière de résidence des données (par exemple, GDPR, PCI DSS) lorsque les cellules doivent s'étendre sur des frontières géopolitiques pour la récupération après sinistre ?
De nombreux candidats négligent les implications juridiques du placement des cellules. L'architecture met en œuvre des cellules géo-clôturées où le stockage principal des données reste dans des frontières souveraines, tandis que les cellules secondaires agissent comme des réserves chaudes cryptées avec des capacités de destruction cryptographique. Les techniques de cryptographie homomorphe permettent aux algorithmes de détection de fraude de fonctionner sur des données transfrontalières cryptées sans déchiffrer des PII sensibles dans des juridictions étrangères. Le routage du trafic des cellules intègre un DNS conscient de la géolocalisation (Route 53 routage par géoproximité) pour garantir que les clients de l'UE ne traversent jamais les cellules américaines à moins d'être explicitement autorisés pour des scénarios de récupération après sinistre, avec des audits automatisés de résidence des données vérifiant la conformité de placement des cellules par le biais de Infrastructure as Code (IaC) scanning.
Quels mécanismes empêchent les problèmes de "troupeau tonnerre" lorsqu'une cellule défaillante se rétablit et que des milliers de clients tentent simultanément de se reconnecter, submergeant l'instance restaurée ?
Ce problème opérationnel subtil est souvent négligé. La solution emploie une limitation de taux par seau de jetons au niveau de la Porte d'Entrée API spécifiquement pour la réintégration des cellules, couplée à un retard exponentiel aléatoire dans les SDK clients. Lors de la récupération de la cellule, le plan de contrôle augmente progressivement le poids du routage en utilisant une interpolation linéaire de 0 % à 100 % sur une période de 15 minutes tout en surveillant la latence p99 et les taux d'erreur. Le pool de connexions avec des limites de concurrence adaptatives dans Envoy empêche l'épuisement des connexions, tandis que des requêtes de préchauffage (transactions synthétiques) valident la santé de la cellule avant d'accepter le trafic client. Des travaux de préchauffage du cache peuplent proactivement les clusters Redis dans la cellule en cours de récupération pour prévenir le stampede de cache sur le stockage à froid.