Faire évoluer les passerelles de paiement au-delà d'un million de transactions par jour

Une passerelle de paiement qui traite 100 000 transactions par jour présente des goulots d'étranglement différents de celle qui en traite 1 million. L'architecture qui vous a amené à 100 000 ne vous amènera pas à 1 million sans modifications. L'architecture qui vous amène à 1 million ne vous amènera pas à 10 millions sans modifications supplémentaires. Comprendre quels goulots d'étranglement importent à quelle échelle vous évite de résoudre les mauvais problèmes au mauvais moment.

La transition de 100 000 à 1 million

À 100 000 transactions par jour (~1,2 TPS en moyenne, ~5-10 TPS en pointe), la plupart des architectures fonctionnent. Un monolithe bien conçu ou un petit nombre de services, une base de données primaire unique avec un ou deux réplicas de lecture, et une seule région peuvent gérer cette charge confortablement.

La transition vers 1 million par jour (~12 TPS en moyenne, ~50-100 TPS en pointe) est là où des composants spécifiques commencent à fléchir.

Les écritures en base de données sont le premier goulot d'étranglement le plus courant. Chaque autorisation crée au moins une écriture en base de données - l'enregistrement de transaction - et souvent plusieurs supplémentaires (journal d'audit, mise à jour du solde, clé d'idempotence). À 100 TPS, ce sont 100 écritures par seconde sur potentiellement de nombreuses tables. Le débit d'écriture de la base de données primaire devient une contrainte.

Atténuation avant d'avoir besoin de réplicas de lecture et de sharding : identifiez quelles écritures sont dans le chemin critique (doivent se terminer avant l'envoi de la réponse) et lesquelles ne le sont pas (journaux d'audit, événements analytiques). Déplacez les écritures non critiques vers une file d'attente asynchrone. Cela réduit considérablement la pression d'écriture sur le chemin critique.

Voir aussi : Les erreurs d'architecture les plus courantes dans les passerelles de paiement

L'épuisement du pool de connexions est le deuxième goulot d'étranglement courant. À une concurrence plus élevée, les instances d'application épuisent leurs pools de connexions de base de données. Les symptômes ressemblent à des pics de latence avec le CPU de la base de données à 30 % - la base de données n'est pas surchargée, mais les threads d'application attendent des connexions.

PgBouncer ou un pooler de connexions équivalent en mode transaction élimine ce goulot d'étranglement. Les instances d'application se connectent au pooler ; le pooler maintient un ensemble plus petit de connexions réelles à la base de données. C'est l'une des optimisations à plus fort levier disponibles.

La transition de 1 million à 10 millions

À 10 millions de transactions par jour (~120 TPS en moyenne, ~500-1000 TPS en pointe), le modèle de base de données à primaire unique atteint ses limites pour les charges de travail en écriture intensive. Les solutions dépendent de votre modèle de données.

Mise à l'échelle en lecture avec des réplicas : la plupart des charges de travail de paiement sont en lecture intensive. Les vérifications du statut d'autorisation, les requêtes de solde et les rapports lisent bien plus qu'ils n'écrivent. Acheminer les requêtes de lecture vers les réplicas réduit significativement la charge primaire. L'exigence d'ingénierie est de s'assurer que les réplicas de lecture sont utilisés pour les requêtes pouvant tolérer un lag de réplication, et que le primaire est utilisé pour les requêtes qui ne le peuvent pas.

Mise à l'échelle en écriture avec le sharding : pour les plateformes où le volume d'écriture est la contrainte, le sharding distribue la charge d'écriture sur plusieurs bases de données primaires. Fragmentez par identifiant client ou marchand - l'identifiant qui détermine quelle partition de base de données gère une transaction donnée. La complexité du sharding réside dans les opérations cross-shard (un paiement du client A vers le client B dans des shards différents) et dans la garantie que la distribution des clés de shard est suffisamment équilibrée pour éviter les shards chauds.

Règlement asynchrone : à volume élevé, le budget de latence pour les opérations synchrones devient très serré. Séparez la décision d'autorisation (faible latence, synchrone) de l'opération de règlement (latence plus élevée, peut être asynchrone). L'autorisation réussit ou échoue en millisecondes. Le règlement est traité en arrière-plan. Ce découplage permet d'optimiser chacun indépendamment.

Voir aussi : L'observabilité pour les systèmes critiques de transaction

Intégration PSP à grande échelle

À plus d'un million de transactions par jour, les limites d'API PSP deviennent une contrainte réelle. Les PSPs limitent le débit par clé API, par marchand et parfois par réseau de cartes. Comprendre les limites de votre PSP et à quel point vous en êtes proche est un travail opérationnel qui doit se faire avant de les atteindre.

Stratégies d'atténuation :

• Diversification du routage : répartissez le volume de transactions sur plusieurs PSPs. Cela réduit l'exposition aux limites de débit individuelles et aux dégradations individuelles.
• Regroupement des requêtes : là où le PSP le supporte, regroupez les vérifications d'autorisation ou les requêtes de capture. Tous les PSPs ne supportent pas cela pour les autorisations.
• Webhooks asynchrones : si votre flux d'autorisation déclenche des webhooks en aval, traitez-les de façon asynchrone avec une file d'attente plutôt qu'en ligne avec la réponse d'autorisation.

Les tests de charge comme pratique d'ingénierie

À grande échelle, le seul moyen de trouver les goulots d'étranglement avant que les utilisateurs ne les trouvent est le test de charge. Les tests de charge doivent être :

• Réalistes : utilisez des schémas de transaction qui correspondent à la production. Un test de charge avec un seul marchand et un seul réseau de cartes ne trouvera pas les goulots d'étranglement qui apparaissent avec du trafic multi-marchands et multi-réseaux.
• Soutenus : les tests de charge de pointe importent, mais une charge soutenue à 80 % du pic pendant 30 minutes révèle des goulots d'étranglement que les pics d'une minute ne révèlent pas.
• Instrumentés : effectuez des tests de charge avec une observabilité complète active. La requête de base de données qui est lente à 100 TPS mais acceptable à 10 TPS apparaîtra clairement dans les traces.

Voir aussi : Comment réduire les coûts d'infrastructure de paiement de 30 %

---

Si votre passerelle approche d'un seuil de montée en charge et que vous n'êtes pas sûr des goulots d'étranglement qui apparaîtront en premier, une évaluation de scalabilité les identifiera avant que vos utilisateurs ne le fassent.

Notre service d'ingénierie de scalabilité et de performance couvre l'ensemble de la chaîne, du débit d'écriture en base de données jusqu'au routage PSP et au basculement multi-région.