Cada engagement de arquitectura que involucra integración de sistemas eventualmente llega a la misma pregunta: ¿construimos una capa de middleware propia, o aceptamos la superficie de integración del vendor tal como está?
La respuesta equivocada es cara en cualquiera de las dos direcciones. Veamos cuándo cada una es la correcta.
Qué significa “middleware” aquí
Por middleware me refiero a un servicio o capa propiedad de tu equipo que se sienta entre dos sistemas y traduce entre ellos. Puede manejar autenticación, retries, conversión de formato, encolamiento, throttling, o lógica de negocio que no pertenece a ninguno de los dos sistemas.
La alternativa es dejar que los sistemas se hablen directamente usando lo que el vendor provee — SDKs, webhooks, endpoints REST — y absorber las limitaciones de esa interfaz en el código de tu aplicación.
Cuándo construirlo
Hay cuatro señales que justifican un middleware propio:
Necesitas cambiar comportamiento que el vendor no expone. Si el webhook del vendor se dispara una sola vez y tu negocio requiere tres retries con exponential backoff más una alerta en el segundo retry — y el vendor no lo soporta — necesitas una capa que sí.
El mismatch de protocolo es estructural. Si tu plataforma habla eventos y el vendor habla request/response, cada consumidor de esa integración va a pagar el costo de hacer ese puente. Centralizarlo en un lugar es más barato que 12 implementaciones parciales.
Esperas cambiar de vendor. Un middleware propio abstrae al vendor. Si tu CRM, billing o proveedor de telefonía puede cambiar en los próximos 24 meses, el middleware es lo que salva la migración.
Necesitas audit, compliance u observabilidad más allá de lo que el vendor ofrece. Industrias reguladas suelen necesitar que cada llamada sea logueada, firmada o enrutada por una región específica. El middleware es donde eso vive.
Cuándo no hacerlo
Un middleware propio es una de las piezas de código más caras que vas a tener. Hay que deployarlo, monitorearlo, escalarlo, asegurarlo, y actualizarlo cada vez que cualquiera de los dos lados cambie. Si ninguna de las cuatro señales aplica, sáltatelo.
Específicamente, sáltatelo cuando:
- La interfaz del vendor ya cubre tus necesidades end-to-end.
- La integración es una de muchas de bajo volumen donde el costo de mantener un middleware excede el costo de duplicar lógica en el cliente.
- El vendor es genuinamente estratégico para tu negocio y cambiarlo es implausible (estás integrado a Stripe y no te vas a ir de Stripe).
- Tu equipo no tiene el bandwidth para operar el middleware como infraestructura productiva.
Un ejemplo real
En un engagement reciente, el cliente integró su plataforma de servicio al cliente (Freshworks) con su sistema operacional core (un BOS propio). Freshworks no tenía concepto nativo de las entidades primarias del BOS, y el BOS no tenía concepto de tickets.
Una integración directa habría significado que cada plugin o workflow de Freshworks que necesitara data del BOS tendría que conocer la API, el modelo de auth y los rate limits del BOS. Modelamos los puntos de integración y contamos doce viniendo en el siguiente año.
La decisión fue fácil: una capa de middleware propia que exponía una API estable y opinionada a Freshworks y traducía las llamadas al BOS por debajo. El middleware también manejaba retries, audit logging, y una cola para operaciones asíncronas que el BOS no podía procesar de forma síncrona.
Costo: un ingeniero por 12 semanas. Beneficio: cada nuevo punto de integración se entrega en días, no semanas, y un cambio futuro de vendor es un problema contenido.
El framework de decisión
Antes de comprometerte, escribe:
- ¿Qué capacidad agrega el middleware que el vendor no te da?
- ¿Cuántos consumidores van a usar el middleware?
- ¿Qué pasa si no lo construyes — cuál es el costo duplicado?
- ¿Quién lo opera después de que entregues?
Si no puedes responder la 4, no deberías construirlo. Un middleware sin un equipo que lo opere es deuda técnica con uniforme.