Imagina que tienes dos amigos: uno vende productos (Order Service) y otro maneja pagos (Payment Service). Cuando vendes algo, necesitas asegurarte de que el pago se procese correctamente. Pero ¿cómo pruebas que ambos "hablan el mismo idioma" sin romper nada?

Este proyecto demuestra Pact Testing - una forma de probar contratos entre microservicios. Es como un acuerdo escrito que dice: "Si me das estos datos, te devolveré estos otros". Si alguien cambia el acuerdo sin avisar, las pruebas fallan.

• Trabajo: Recibe pedidos de clientes, valida datos, guarda pedidos.
• Comunica: Envía pedidos a Payment Service vía HTTP, y publica eventos a Kafka.

• Trabajo: Procesa pagos cuando recibe notificaciones de pedidos.
• Comunica: Recibe pedidos vía HTTP, consume eventos de Kafka para procesar pagos.

Síncrona: Como una llamada telefónica.

• Order Service llama a Payment Service: "Crea este pedido"
• Payment Service responde: "OK, aquí está el pedido creado"

Pact verifica: ¿La respuesta tiene todos los campos que Order Service espera?

Asíncrona: Como dejar un mensaje en el contestador.

• Order Service publica: "Nuevo pedido creado"
• Payment Service consume y procesa: "Voy a cobrar este pedido"

Por qué no Pact? Pact es para APIs HTTP. Kafka es comunicación interna.

Order Service (consumidor) dice: "Espero que cuando envíe estos datos, reciba esta respuesta".

// En realPact.test.js
await provider.addInteraction({
  uponReceiving: 'a request to create an order',
  withRequest: { /* datos que envío */ },
  willRespondWith: { /* datos que espero recibir */ }
});

Las pruebas crean un archivo JSON (el "contrato") que dice exactamente qué debe pasar.

Es como un notario que guarda el contrato. Ambos servicios pueden verlo.

Payment Service (proveedor) lee el contrato y verifica: "¿Puedo cumplir con esto?"

Si no, ¡fallo! Alguien cambió el acuerdo sin avisar.

# Terminal 1: Payment Service
cd payment-service && npm run dev

# Terminal 2: Pact Broker
cd pact-broker && docker-compose up -d

cd order-service && npm run test:pact

cd order-service && node scripts/publish-pacts.js

cd payment-service && node scripts/verify-pacts.js

Agregamos un campo description a la respuesta esperada en el contrato. Pero Payment Service no lo devuelve. ¡Fallo!

Lección: Los cambios en contratos deben ser coordinados entre servicios.

Como un recibo de compra: especifica qué das y qué recibes. Si el recibo cambia, ambos deben acordar.

En microservicios, cambiar un servicio puede romper otros. Pact detecta esto antes de deploy.

• Consumidor: Quien usa el servicio (Order Service usa Payment Service).
• Proveedor: Quien provee el servicio (Payment Service).

No. Solo contratos HTTP. Para Kafka, necesitas otras pruebas (unitarias, integración).

• order-service/tests/pact/realPact.test.js: Define expectativas del consumidor.
• payment-service/scripts/verify-pacts.js: Verifica que el proveedor cumpla.
• order-service/src/services/orderService.js: Lógica de negocio + eventos Kafka.
• pact-broker/: Almacén de contratos.

OrderEvent es para Kafka (interno). Pact es para APIs HTTP entre servicios.

Depende. Para APIs: actualiza proveedor, luego consumidor. Para interno: modelo primero.

Desacopla servicios. Order Service crea pedido, publica evento. Payment Service reacciona automáticamente.

¡Ahora entiendes cómo Pact asegura que tus microservicios "hablen el mismo idioma"!