under_codeUnder Code — inicio
← insights

20 de agosto de 2026·5 min de lectura

Qué revisar antes de integrar un sistema nuevo a una plataforma que ya opera

Cada integración nueva es una promesa implícita a todo lo que ya depende de esa plataforma. Un criterio simple para no romperla al cumplirla.

Trabajé el roadmap y backlog de producto de DealHub, con foco en integrar sistemas y APIs al ecosistema tecnológico de Cencosud — uno de los casos que detallamos en la sección de trayectoria de este sitio. La restricción real de ese trabajo no era técnica en el sentido de "es difícil de construir"; era que la plataforma ya tenía años de sistemas dependiendo de ella, y cada cambio corría el riesgo de romper algo que nadie en la sala recordaba que dependía de ese comportamiento específico.

Esa es la diferencia entre integrar sobre una plataforma nueva y hacerlo sobre una que ya opera: en la segunda, lo que no se rompe importa tanto como lo que se construye. Esto es lo que reviso antes de aprobar una integración nueva sobre un sistema en producción.

Primero, quién más consume lo que estás a punto de cambiar. Antes de modificar un endpoint, un esquema de datos o un contrato de API, hay que tener el mapa real de quién lo consume hoy — no el mapa de la documentación, que casi siempre queda desactualizado, sino el que sale de revisar logs de tráfico real. Es sorprendente cuántas veces aparece un consumidor que nadie recordaba.

Segundo, versionar en vez de reemplazar. Un contrato de API nuevo no debería forzar a todos los consumidores existentes a migrar el mismo día. Mantener la versión anterior viva durante un período de transición cuesta más trabajo de mantenimiento en el corto plazo, pero cuesta mucho menos que un incidente en producción un lunes en la mañana.

Tercero, probar la integración con datos reales de producción, no solo con los datos de prueba que el equipo construyó para que el caso feliz funcione. Los datos reales tienen los casos borde que nadie diseñó a propósito: campos vacíos, formatos inconsistentes de sistemas legados, encoding distinto. Ahí es donde una integración que se veía lista en ambiente de pruebas falla en producción.

Cuarto, tener un plan de reversa antes de desplegar, no improvisado después del incidente. Si la integración nueva falla en producción, ¿cuánto se tarda en volver al estado anterior, y quién tiene la autoridad para tomar esa decisión sin escalar por tres niveles de aprobación mientras el sistema sigue caído?

Ninguno de estos cuatro puntos aparece en la demo de la integración funcionando. Aparecen recién cuando algo falla — y para entonces, ya es tarde para haberlos pensado con calma.

  • APIs
  • Integración

Escrito por

Javier Gajardo PérezCo-founder · Producto y Delivery, Under Code

$agenda una conversación técnica