Serie 2: Resilient Architecture — Production Patterns

#typescript #webdev #backend

The Problem

When a payment processing system fails to handle successful payments correctly, it can lead to inconsistent order states and frustrated customers. This implementation exists to ensure that when a payment is successfully processed, the corresponding order status is updated in a timely manner. The code snippet is designed to handle the payment confirmation from a payment gateway and update the order status to 'PAID' in the system.

If this implementation is missing or incorrect, it can result in duplicate charges or orders being stuck in a pending state, causing customer support issues and potential revenue loss. For instance, if the order status is not updated correctly, the system may attempt to process the payment again, leading to duplicate charges.

One trade-off of this implementation is that it may introduce additional latency in the payment processing flow, as it relies on the orderRabbitClient to update the order status.

What is the best approach to handle cases where the payment gateway confirms a payment, but the order update fails due to a system error, and how do you ensure that the system remains consistent in such scenarios?

The Implementation

      throw new BadRequestException('Error al procesar el pago');
    }
  }

  async handleSuccessfulPayment(data: {
    paymentId: string;
    status: string;
    orderId: string;
    merchantOrderId?: string;
    preferenceId?: string;
  }) {
    this.logger.log(`💰 Procesando pago exitoso: ${data.paymentId}`);

    try {
      const updatedOrder = await this.orderRabbitClient.updateOrderPaymentStatus(
        data.orderId,
        {
          paymentId: data.paymentId,
          paymentStatus: 'PAID',
          paymentDate: new Date(),
        });

Why This Matters in Production

This pattern directly prevents common failure modes in distributed systems.
Without it, you're exposed to race conditions, data inconsistency, and cascading failures.

Trade-offs

Every architectural decision has a cost. This approach adds complexity to your
codebase and requires your team to understand the pattern deeply before modifying it.