Rotación de proxies: la ingeniería aburrida que decide si tu infraestructura sobrevive
Detrás de cualquier sistema que hace muchas peticiones salientes hay un problema poco glamoroso pero crítico: cómo saber, antes de que sea tarde, qué recursos ya no sirven.
Cualquier sistema que necesita hacer un volumen alto de peticiones salientes hacia destinos externos (scraping, verificación de datos, automatización) eventualmente choca con un problema que no tiene nada que ver con la lógica de negocio: los recursos de red que usa para salir (proxies, direcciones IP, identidades de conexión) tienen una vida útil limitada e impredecible, y el sistema necesita saber cuándo uno dejó de funcionar antes de que ese fallo contamine el resultado de una operación completa.
Por qué esto no es "solo usar un proxy"
La solución ingenua es tratar la lista de proxies disponibles como una simple rotación: usar el primero, si falla pasar al segundo, y así sucesivamente. Esto funciona mientras el volumen es bajo y los fallos son raros. Se rompe en cuanto el volumen crece, porque introduce dos problemas que la rotación simple no contempla.
Validación reactiva vs. proactiva. Descubrir que un proxy ya no funciona solo cuando una petición real falla significa que cada fallo de proxy se traduce directamente en un fallo visible de negocio. La alternativa madura es validar la salud de cada recurso de forma independiente y continua, en segundo plano, para que el sistema sepa de antemano cuáles están disponibles antes de necesitarlos para una operación real.
Fallos correlacionados, no independientes. Cuando un proxy empieza a fallar, no suele fallar de forma aislada y aleatoria. Suele fallar de forma correlacionada: toda una franja de direcciones de un mismo proveedor se degrada al mismo tiempo, o un patrón de uso específico (volumen alto en poco tiempo) hace que varios recursos se marquen como sospechosos simultáneamente. Un sistema que trata cada fallo como un evento aislado no detecta el patrón hasta que ya perdió una porción significativa de su capacidad operativa.
El diseño que sí escala
La solución robusta separa dos responsabilidades que la rotación simple mezcla en una sola: por un lado, un proceso de salud que evalúa continuamente el estado de cada recurso disponible (tiempos de respuesta, tasa de error, señales de bloqueo) y mantiene un estado actualizado de cuáles son confiables ahora mismo; por otro lado, la lógica de asignación, que consulta ese estado antes de elegir qué recurso usar para la siguiente operación, en lugar de descubrir el fallo en el momento de usarlo.
Esta separación permite además una capacidad crítica que la rotación simple no tiene: retirar proactivamente un recurso completo (o una franja completa) del pool disponible cuando la señal de degradación es clara, en lugar de esperar a que cada petición individual falle una por una antes de reaccionar.
La lección
Este es exactamente el tipo de problema de ingeniería que no aparece en ninguna arquitectura de referencia bonita, pero que determina si un sistema con dependencias de red externas de alto volumen es confiable o se degrada de forma impredecible bajo su propio peso. La diferencia entre un sistema que escala con gracia y uno que colapsa silenciosamente casi nunca está en la lógica de negocio central. Está en decisiones aburridas como esta: cómo saber, con anticipación y no por accidente, qué recursos ya no sirven.