¿Por qué los sistemas de pago son sistemas distribuidos? (Por Que Los Sistemas DE Pago Son Sistemas Distribuidos)

El pago no es un botón, es una coordinación

Cuando dice "recibir pago" en una plataforma de comercio electrónico, en realidad quiere que cinco sistemas diferentes se pongan de acuerdo sobre los mismos hechos: si el carrito está congelado, si hay stock, si la pasarela del proveedor recibió el dinero, si se confirmó el pedido, si el registro financiero es correcto. Todos estos no viven en un solo proceso, una sola transacción.```text Sepet Servisi Stok Servisi Checkout Orchestrator Provider Gateway Finans/Ledger | | | | | +---------------+------------------+--------------------+----------------+ aynı sipariş, beş farklı gerçek

## Conceptos en la primera mención```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.
```Incapaz de distinguir estos cinco conceptos, un equipo obliga a la PSP a actuar como su propia base de datos. PSP nunca participa en su transacción; simplemente comunica su propia verdad, en su propia línea de tiempo.

## La solicitud única requiere cinco firmas

Cuando un cliente presiona el botón "Pagar", se toman las siguientes decisiones en segundo plano: si el precio de la cesta se congela, si se reservan las existencias, si la solicitud de pago se envía a la pasarela del proveedor, si el PSP retira el dinero, si se finalizan las líneas de pedido, si se abre el registro financiero. Cada uno de ellos es responsabilidad de un servicio diferente y reside en una base de datos diferente.

Aquí es donde comienza el problema: si llamas a estos seis pasos de forma sincrónica dentro de una única cadena de solicitud HTTP, el sistema se convierte en una larga y frágil cadena de dependencias de un único punto a otro.```text
Client → Checkout Orchestrator → Sepet Servisi → Stok Servisi → Provider Gateway → PSP
```## ¿Dónde se rompe la cadena síncrona?

Cuando cualquier paso de esta cadena emite un tiempo de espera, surgen dos preguntas: ¿Llegó la solicitud a la otra parte y, de ser así, se procesó? Un tiempo de espera al regresar de PSP no significa que “no se retirará dinero”; Significa "No obtuve la respuesta". Volver a enviar la misma solicitud podría dejar al cliente en el cajero dos veces.```text
Checkout Orchestrator --(timeout)--> Provider Gateway --(???)--> PSP
                                                        para çekildi mi, çekilmedi mi?
```Esta incertidumbre es una consecuencia natural de la cadena síncrona: la red es, por definición, poco fiable; Cuanto más se extiende la cadena, más incertidumbre se acumula.

## Por qué “todo o nada” no funciona aquí

Las soluciones clásicas de transacciones distribuidas (como el compromiso de dos fases) esperan que todos los participantes tengan el mismo coordinador, el mismo protocolo de bloqueo y la misma confiabilidad de la red. PSP no es parte de este mundo: no se desbloquea sola, no escucha su llamada de confirmación/reversión, le notifica en su propia línea de tiempo (webhook, notificación retrasada).

Por lo tanto, intentar encajar el trío "pago + stock + pedido" en una sola transacción es hacer que un problema irresoluble parezca resuelto. Lo que en realidad estás haciendo es ocultar el error; No lo has eliminado.

## Solución basada en eventos: dos hechos diferentes, dos cronogramas diferentes

El modelo de trabajo es acortar la cadena síncrona y delegar el resto a eventos. Usted envía una solicitud a la puerta de enlace del proveedor, registra la respuesta del PSP (sincrónicamente o mediante webhook) como un evento, y cada paso en el lado del pedido/inventario/finanzas es un consumidor idempotente por derecho propio, que reacciona a este evento.```text
Provider Gateway → PaymentCaptured (event) → Outbox
                                              ↓
                         Stok Servisi   Finans Servisi   Checkout Orchestrator
                         (bağımsız, kendi hızında, kendi retry'ıyla tüketir)
```En este modelo, “pago exitoso” y “pedido completado” ya no son un evento único que ocurre al mismo tiempo, sino dos hechos separados que se suceden, con un retraso mensurable entre ellos. Los sistemas que no aceptan esta distinción progresan hacia errores de máquina de estados, que veremos en la segunda parte de esta serie.

## Los enfrentamientos más confusos de este episodio.```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
```Estos cuatro desajustes son la raíz de la mayoría de los incidentes de "por qué a veces se cobra dos veces el pago".

## Lista de verificación de su propio sistema

1. ¿Cuántos servicios diferentes escriben en cuántas bases de datos diferentes en su flujo de pagos? Escribe este número.
2. ¿Su código vuelve a intentarlo automáticamente cuando se agota el tiempo de espera de la llamada al portal del proveedor? ¿Este reintento lleva una clave de idempotencia?
3. ¿La información de "pago exitoso" y la información de "pedido completado" se mantienen en la misma fila o en tablas diferentes?
4. Si el webhook de la PSP se retrasa o no llega, ¿cuántas horas le toma a su sistema darse cuenta?
5. ¿Cuál es el paso más largo de su cadena sincrónica y qué hacen los pasos restantes si ese paso cae?

Si no tiene respuestas claras a estas cinco preguntas, su flujo de pagos probablemente esté diseñado con la ilusión de una "única transacción".

## Cosas para recordar de esta sección

1. Un pago no es la transacción de un solo servicio; Es una coordinación en la que la canasta, el stock, la pasarela de proveedores y las finanzas coinciden en un mismo hecho.
2. La cadena HTTP síncrona acumula incertidumbre multiplicándola en cada paso adicional; El tiempo de espera no es un resultado, es una incertidumbre.
3. PSP no forma parte de su límite de transacciones; le hablas con un contrato de evento, no con un bloqueo sincrónico.
4. La coherencia final no es una deficiencia, sino una aceptación del comportamiento real del mundo exterior (especialmente del PSP).

> Si diseña el sistema de pago como "instantáneo y en una sola pieza", se encontrará con la realidad de una producción "retrasada y de varias piezas".