Cómo migrar una API de pagos de SOAP a microservicios NestJS sin tumbar producción

Si llevas tiempo en pagos, conoces la escena: una API que tarda decenas de segundos cuando el negocio necesita milisegundos. No es un edge case. Es el tipo de deuda que frena integraciones, dispara tickets y hace que los partners busquen alternativas.

Desde Caracas, en remoto con equipos internacionales, lideré esa migración en Andrómeda Ventures: de un monolito SOAP a microservicios con NestJS, PostgreSQL y Redis. El caso de estudio completo está en mi portfolio; aquí va la guía que hubiera querido leer antes de empezar.

Si buscas el deep dive técnico con código legacy y arquitectura detallada, lee también De 60 segundos a milisegundos: refactorizando el core de pagos de Andrómeda.

1. Diagnóstico: dos semanas sin escribir microservicios

Antes de diseñar nada, mapeamos flujos críticos:

• Recargas prepago
• Confirmación de pago
• Conciliación con operadores
• Notificaciones a partners

Para cada uno medimos p50, p95 y p99 — no promedios que esconden el dolor real.

Dos hallazgos cambiaron el plan:

1. ~80% del tiempo se iba en llamadas síncronas a operadores externos.
2. Dominios distintos compartían tablas y locks.

Conclusión: el problema no era Node vs Java. Era acoplamiento.

2. Bounded contexts, no microservicios por moda

Dividir por capas (API / DB / colas) solo mueve el monolito de sitio. Alineamos servicios al negocio:

Regla práctica: si dos equipos no evolucionan algo de forma independiente, no lo separes todavía. Terminamos con cuatro servicios principales, no catorce.

Más contexto de arquitectura en Arquitectura backend y microservicios.

3. NestJS: estructura que aguanta presión de pagos

Elegimos NestJS porque el equipo dominaba Node.js y necesitábamos límites explícitos: módulos, DI, guards, interceptors.

API Gateway centralizó auth, rate limiting y routing. Los microservicios no exponen endpoints públicos directos.

PostgreSQL con particionamiento por operador y rango de fechas. Índices diseñados con las queries de conciliación, no después.

Redis + BullMQ para lo que no debe bloquear el happy path: notificaciones, reintentos, conciliación diferida.

Circuit breakers por integración externa. Si un operador degrada, cortas tráfico antes de arrastrar el pool de conexiones.

4. Idempotencia: no negociable

En pagos, un timeout sin idempotency key es un doble cobro potencial. Diseñalo desde el primer endpoint:

• Keys idempotentes por operación
• Estados de transacción explícitos
• Reintentos con backoff exponencial
• Correlation ID en logs de punta a punta

5. Migrar sin big bang: strangler fig

No apagamos SOAP de un día para otro. Rutamos tráfico incrementalmente al stack NestJS mientras el legacy convivía para flujos pendientes.

CI/CD con Docker y despliegues blue-green para releases sin downtime. Observabilidad de negocio desde el día uno: TPS por dominio, latencia por integración, transacciones pendientes > N minutos.

Resultados en Andrómeda Ventures

Después de la migración completa:

• De ~60 segundos a menos de 100 ms en el camino crítico
• 99.8% de mejora en tiempo de respuesta
• 1000+ TPS sostenidos en picos
• Integración con Stripe, Ingenico y Mercadopago sin reescribir el core cada vez

¿Solo por microservicios? No. Fue async donde correspondía, dominios claros y dejar de confiar ciegamente en integraciones externas.

Cinco lecciones concretas

1. No migres por religión. Migra cuando el monolito cuesta más que convivir con él.
2. Idempotencia desde el día uno. No después del primer incidente.
3. Gateway con propósito. Protege contratos públicos y centraliza lo transversal.
4. Métricas de negocio > dashboards bonitos. TPS y estados pendientes alertan antes que soporte.
5. Remoto exige claridad. Desde Venezuela para clientes en US y Europa: documentación, entregas pequeñas y comunicación escrita impecable.

¿Proyecto similar?

• Consultoría FinTech — pagos, e-wallets, APIs de alto volumen
• Caso Andrómeda Ventures — métricas y stack completos
• Kit de prensa — para medios y entrevistas LATAM
• Contacto — agenda una llamada

Sobre el autor: Miguel Mendoza Chourio (Chourio DEV) es ingeniero FinTech y arquitecto de software senior en Venezuela, 9+ años construyendo sistemas de pago y microservicios para equipos remotos internacionales.