Pourquoi les systèmes de paiement sont-ils des systèmes distribués ? (Pourquoi Les Systemes DE Paiement Sont Ils Des Systemes Distribues)

Le paiement n'est pas un bouton, c'est une coordination

Lorsque vous dites « accepter le paiement » sur une plateforme de commerce électronique, vous voulez en fait que cinq systèmes différents s'accordent sur les mêmes faits : le panier est-il gelé, y a-t-il du stock, la passerelle du fournisseur a-t-elle reçu l'argent, la commande a-t-elle été confirmée, le dossier financier est-il correct. Tout cela ne réside pas dans un seul processus, une seule transaction.```text Sepet Servisi Stok Servisi Checkout Orchestrator Provider Gateway Finans/Ledger | | | | | +---------------+------------------+--------------------+----------------+ aynı sipariş, beş farklı gerçek

## Concepts à la première mention```text
📦 Checkout Orchestrator
Sipariş akışının adımlarını (sepet, ödeme, stok, onay) koordine eden servis; para veya stok tutmaz, kararları sıralar.

📦 Provider Gateway
Gerçek ödeme sağlayıcısını (PSP) uygulama iç modeline çeviren soyutlama katmanı.

📦 PSP (Payment Service Provider)
Kartı veznede tutan, parayı fiilen çeken dış sistem; sizin transaction sınırınızın dışındadır.

📦 Dağıtık Transaction
Birden fazla bağımsız sistemin, tek bir “hepsi ya da hiçbiri” garantisi altında değişmesi gereken işlem.

📦 Eventual Consistency
Sistemlerin şu an değil, kısa bir süre içinde aynı gerçeğe yakınsayacağını kabul eden tutarlılık modeli.
```Incapable de distinguer ces cinq concepts, une équipe force la PSP à agir comme sa propre base de données. PSP ne participe jamais à votre transaction ; il communique simplement sa propre vérité, dans sa propre chronologie.

## Une seule demande nécessite cinq signatures

Lorsqu'un client appuie sur le bouton « Payer », les décisions suivantes sont prises en arrière-plan : si le prix du panier est gelé, si le stock est réservé, si la demande de paiement est envoyée à la passerelle du fournisseur, si le PSP retire l'argent, si les lignes de commande sont finalisées, si le dossier financier est ouvert. Chacun d’entre eux relève de la responsabilité d’un service différent et réside dans une base de données différente.

C'est là que le problème commence : si vous appelez ces six étapes de manière synchrone au sein d'une seule chaîne de requêtes HTTP, le système devient une chaîne longue et fragile de dépendances d'un point à un autre.```text
Client → Checkout Orchestrator → Sepet Servisi → Stok Servisi → Provider Gateway → PSP
```## Où se casse la chaîne synchrone ?

Lorsqu'une étape de cette chaîne émet un délai d'attente, vous vous posez deux questions : la demande est-elle parvenue à l'autre partie et, si oui, a-t-elle été traitée ? Un timeout revenant de la PSP ne signifie pas « aucun argent retiré » ; Cela signifie « Je n’ai pas obtenu la réponse ». Soumettre à nouveau la même demande pourrait laisser le client à la caisse deux fois.```text
Checkout Orchestrator --(timeout)--> Provider Gateway --(???)--> PSP
                                                        para çekildi mi, çekilmedi mi?
```Cette incertitude est une conséquence naturelle de la chaîne synchrone : le réseau est, par définition, peu fiable ; Plus vous prolongez la chaîne, plus l’incertitude s’accumule.

## Pourquoi « tout ou rien » ne fonctionne pas ici

Les solutions de transactions distribuées classiques (telles que la validation en deux phases) s'attendent à ce que tous les participants disposent du même coordinateur, du même protocole de verrouillage et de la même fiabilité du réseau. La PSP ne fait pas partie de ce monde : elle ne se déverrouille pas, elle n'écoute pas votre appel commit/rollback, elle vous notifie sur sa propre timeline (webhook, notification différée).

Par conséquent, tenter d’intégrer le trio « paiement + stock + commande » en une seule transaction donne l’impression qu’un problème insoluble a été résolu. Ce que vous faites en réalité, c'est cacher l'erreur ; Vous ne l'avez pas éliminé.

## Solution basée sur les événements : deux faits différents, deux délais différents

Le modèle de travail consiste à raccourcir la chaîne synchrone et à déléguer le reste aux événements. Vous envoyez une demande à la passerelle du fournisseur, enregistrez la réponse du PSP (de manière synchrone ou via webhook) en tant qu'événement, et chaque étape du côté commande/inventaire/financement est un consommateur idempotent à part entière, réagissant à cet événement.```text
Provider Gateway → PaymentCaptured (event) → Outbox
                                              ↓
                         Stok Servisi   Finans Servisi   Checkout Orchestrator
                         (bağımsız, kendi hızında, kendi retry'ıyla tüketir)
```Dans ce modèle, « paiement réussi » et « commande terminée » ne sont plus un événement unique se produisant en même temps, mais deux faits distincts qui se succèdent, avec un délai mesurable entre eux. Les systèmes qui n’acceptent pas cette distinction progressent vers des erreurs de machine à états, ce que nous verrons dans la deuxième partie de cette série.

## Les confrontations les plus déroutantes de cet épisode```text
❌ Ödeme akışı = tek bir servisin fonksiyonu
✓ Ödeme akışı = birden fazla bağımsız servisin katıldığı bir koordinasyon

❌ PSP = bizim veritabanımızdaki bir tablo gibi davranır
✓ PSP = kendi zaman çizelgesi olan, dışarıdan gözlemlenen bir sistem

❌ Timeout = işlem başarısız oldu
✓ Timeout = işlemin sonucu bilinmiyor; retry idempotent olmadan güvenli değildir

❌ Dağıtık transaction ile bu problem “çözülebilir”
✓ Dağıtık transaction, PSP gibi harici sınırlarda pratikte uygulanamaz
```Ces quatre disparités sont à l’origine de la plupart des incidents de type « pourquoi le paiement est-il parfois facturé deux fois ? ».

## Liste de contrôle de votre propre système

1. Combien de services différents écrivent dans combien de bases de données différentes dans votre flux de paiement ? Écrivez ce numéro.
2. Votre code réessaye-t-il automatiquement lorsque l'appel vers la passerelle du fournisseur expire ? Cette nouvelle tentative comporte-t-elle une clé d'idempotence ?
3. Les informations « Paiement réussi » et les informations « Commande terminée » sont-elles conservées dans la même ligne ou dans des tableaux différents ?
4. Si le webhook de la PSP est retardé ou n'arrive pas du tout, combien d'heures faut-il pour que votre système le remarque ?
5. Quelle est l’étape la plus longue de votre chaîne synchrone et que font les étapes restantes si cette étape chute ?

Si vous n'avez pas de réponses claires à ces cinq questions, votre flux de paiement est probablement conçu avec l'illusion d'une « transaction unique ».

## Choses à retenir de cette section

1. Un paiement n’est pas la transaction d’un seul service ; Il s'agit d'une coordination dans laquelle le panier, le stock, la passerelle fournisseur et la finance s'accordent sur le même fait.
2. La chaîne HTTP synchrone accumule l'incertitude en la multipliant à chaque étape supplémentaire ; Le délai d'attente n'est pas un résultat, c'est une incertitude.
3. PSP ne fait pas partie de votre limite de transaction ; vous lui parlez avec un contrat d'événement, pas un verrouillage synchrone.
4. La cohérence éventuelle n'est pas une déficience, mais une acceptation du comportement réel du monde extérieur (en particulier du PSP).

> Si vous concevez le système de paiement comme étant « instantané et en une seule pièce », vous rencontrerez la réalité d'une production « différée et multi-pièces ».