Una investigación funcional y técnica de un fallo distribuido en el procesamiento de pedidos a través de APIs REST, microservicios y mensajería asíncrona.
Sistema
Incidencia
PAY-99821ORD-78451El cargo ya se ha realizado al cliente.
“Tu pago se ha realizado correctamente. Estamos procesando tu pedido.”
Hipótesis
Validación de API
{
"customerId": "CUS-1842",
"items": [
{
"productId": "PROD-901",
"quantity": 2,
"unitPrice": 24.9
}
],
"currency": "EUR"
}201 CreatedOrder = PENDING_PAYMENT{
"orderId": "ORD-78451",
"amount": 49.8,
"currency": "EUR",
"paymentMethod": "CARD"
}200 OKPayment = APPROVEDUna respuesta correcta de la API no garantiza una transacción de negocio correcta.
Contrato de eventos
{
"eventType": "payment.completed",
"eventVersion": "2.0",
"eventId": "evt-78310",
"timestamp": "2026-09-10T09:42:18Z",
"data": {
"orderId": "ORD-78451",
"paymentId": "PAY-99821",
"amount": 49.8,
"currency": "EUR",
"status": "APPROVED"
}
}Unsupported eventVersion: 2.0
Análisis de logs
Payment approved PAY-99821Publishing payment.completed eventPublish successful messageId=MSG-7719Message delivered to order-processing-queueReceived message MSG-7719Parsing event payment.completedERROR Unsupported eventVersion: 2.0; expected 1.0Message moved to DLQCausa raíz
El productor publica eventVersion 2.0, mientras que el Order Processor solo admite la 1.0. El mensaje rechazado termina en la DLQ, por lo que el cliente tiene el cargo realizado mientras el pedido continúa pendiente.
Defecto
| ID | ORD-2173 |
|---|---|
| Título | El pedido permanece en PENDING_PAYMENT tras un pago aprobado debido a una versión del contrato de evento no soportada |
| Severidad | Crítica |
| Afectados | Payment Service · Order Processor |
| Esperado | Pago APPROVED → pedido CONFIRMED → notificación de confirmación |
| Actual | Pago APPROVED; evento rechazado; el pedido permanece en PENDING_PAYMENT |
| Impacto en negocio | Cliente con el cargo realizado y sin pedido confirmado; aumento de contactos con soporte, necesidad de conciliación, riesgo de duplicados y pérdida de confianza. |
Regresión y pruebas de contrato
Validar la compatibilidad productor/consumidor antes del despliegue.
Verificar la publicación, entrega y consumo de eventos.
Checkout → pago → confirmación del pedido → notificación.
Generar alertas cuando lleguen mensajes a la Dead Letter Queue.
POST /orders · 201 CreatedPOST /payments · 200 OKGET /orders/ORD-78451 · expected CONFIRMEDIdempotencia
evt-78310 × 2Si el evento evt-78310 se entrega dos veces, el pedido solo debe pasar a CONFIRMED una vez.
Resultado de la investigación
La investigación permitió acotar el problema desde el flujo completo del pedido hasta la interacción entre el evento de pago y su consumidor.
El productor publicó payment.completed con el contrato de evento v2.0, mientras que el Order Processor solo admitía v1.0.
Las respuestas de las APIs, los payloads de los eventos, los logs de los servicios y el comportamiento de la DLQ se analizaron conjuntamente para validar la hipótesis.
Un pago técnicamente correcto podía dejar al cliente con el cargo realizado y el pedido todavía en PENDING_PAYMENT.
La compatibilidad de contratos entre productor y consumidor se identificó como un riesgo crítico de integración.
Las pruebas de contrato, las pruebas de integración, la validación end-to-end, la idempotencia y la monitorización de la DLQ se identificaron como controles complementarios.
Conclusión
Validar servicios de forma aislada no es suficiente. El sistema completo debe ser capaz de entregar el resultado de negocio esperado.