¿Cómo compruebas que dos servicios siguen funcionando juntos sin levantar el sistema entero?

Usa tests de contrato. El consumidor define las peticiones que hace y la forma de respuesta de la que depende, esa expectativa se publica como contrato, y el proveedor la verifica dentro de su propio pipeline. Así los dos lados testean de forma independiente y rápida, y un cambio incompatible tumba el build del proveedor en vez de aparecer días después en un entorno compartido.

Los entornos completos de extremo a extremo no escalan más allá de un puñado de servicios. Son lentos, necesitan que el último build de cada equipo esté sano a la vez, y cuando algo se pone en rojo la primera pregunta siempre es si es un defecto real o es el entorno. Los tests de contrato esquivan eso. El consumidor escribe tests contra un stub local del proveedor, y esas interacciones quedan registradas como un contrato: para esta petición, dependo de estos campos con estos tipos. Ese contrato se publica, y el propio pipeline del proveedor lo reproduce contra la implementación real. Si alguien renombra un campo o cambia un tipo, su build falla, en su repositorio, minutos después del cambio, con un mensaje que nombra a qué consumidor rompe. Ese es todo el valor: el feedback aterriza donde se hizo el cambio. El matiz que vale la pena decir es que un contrato solo cubre lo que el consumidor usa de verdad, no la superficie completa del proveedor, así que no sustituye a los tests funcionales del proveedor, y verifica compatibilidad y no corrección de negocio. Sigo manteniendo una suite pequeña de extremo a extremo para los pocos recorridos que de verdad hay que demostrar entre servicios.