Depender del servicio de otro
Cada servicio externo que conectas es una parte de tu producto que no controlas y no puedes arreglar. No pasa nada, siempre que lo hayas decidido a propósito.
Conectar una API externa suele ser la vía más rápida para conseguir una capacidad, y traslada en silencio parte de tu fiabilidad a manos ajenas. El trabajo está en decidir qué pasa cuando esa mano resbala.
Decide qué pasa durante una caída antes de la caída
Todo servicio se cae tarde o temprano, en un momento que no eliges. La pregunta que conviene responder mientras nada va mal: ¿tu funcionalidad falla, se degrada o espera?
Fallar es aceptable en algo opcional: un mapa que no carga, un enriquecimiento que queda vacío. No lo es en nada del camino de pago o de acceso, donde necesitas una alternativa o un error honesto que diga qué hacer. Un indicador que gira sin resolverse nunca es el peor resultado, porque enseña a la gente que lo roto es tu producto y no el ajeno.
Las claves son credenciales, no configuración
Una clave de API es una contraseña que resulta estar escrita en un archivo de configuración, y se trata como configuración porque parece un ajuste. Después acaba en el repositorio, en una captura, en un hilo de mensajes.
Mantén las claves fuera del código, usa una clave distinta por entorno para que una prueba nunca toque datos reales, y rótalas cuando se va alguien con acceso. Y da a cada clave el alcance más estrecho que ofrezca el servicio: casi todas las APIs permiten restringir qué puede hacer una clave, y casi nadie lo usa hasta después del incidente que le hizo desearlo.
Los límites de tasa y los reintentos que los empeoran
Lo primero que hace casi toda integración cuando falla una llamada es reintentar de inmediato. Si el fallo era un límite de tasa, acabas de empeorarlo, y una mañana ajetreada se convierte en una caída autoinfligida.
Reintenta con un retraso creciente, limita el número de intentos y luego detente en lugar de girar en bucle. Y nunca reintentes a ciegas una escritura no idempotente: la versión clásica de este fallo es un cliente cobrado dos veces porque la primera llamada sí funcionó y solo se perdió la respuesta.
Cambiará bajo tus pies
Los servicios cambian formatos de respuesta, retiran endpoints y ajustan límites, normalmente anunciándolo donde no estabas leyendo. La integración que lleva un año funcionando no es estable: está sin probar desde la última vez que cambió.
Fija una versión si el servicio la ofrece, suscribe a una persona real a los avisos de cambios en vez de a un buzón compartido que nadie lee, y mantén una llamada automática pequeña que se ejecute a diario y avise cuando la respuesta deje de parecerse a lo de antes. Esta última cuesta una hora y encuentra la rotura antes que un cliente.
Preguntas que la gente hace
¿Qué decidir antes de integrar un servicio externo?
Qué pasa cuando se cae: fallar, degradarse o esperar. Fallar vale para algo opcional; en el camino de pago o acceso necesitas una alternativa o un error honesto. Lo peor es un indicador que gira sin resolverse.
¿Cómo se manejan las claves de API?
Como credenciales, no como configuración. Fuera del repositorio, una clave por entorno para que las pruebas no toquen datos reales, rotación cuando alguien con acceso se va, y el alcance más estrecho posible.
¿Cómo deben funcionar los reintentos?
Con retraso creciente y número limitado de intentos, y luego parar. Reintentar de inmediato convierte un límite de tasa en una caída autoinfligida, y reintentar a ciegas una escritura no idempotente cobra dos veces.
