Infraestructura de automatización de trading
Un endpoint puede responder rápido durante el desarrollo y comportarse de otro modo después de estar sin uso. Para un receptor de alertas, compara el comportamiento del alojamiento durante la inactividad con el plazo de respuesta del emisor antes de confiar en una prueba exitosa con el servicio ya activo.
TradingView indica que una solicitud de webhook se cancela cuando el servidor receptor tarda más de tres segundos en procesarla. La documentación del servicio web Free de Render indica que un servicio inactivo se suspende tras 15 minutos sin tráfico entrante y puede tardar aproximadamente un minuto en volver a iniciarse.
Esos tiempos documentados muestran una incompatibilidad que se debe investigar en esa configuración específica de alojamiento. Un plan gratuito que se suspende por inactividad no debe tratarse como un receptor que responde continuamente solo porque las solicitudes repetidas funcionan mientras está activo. Es una inferencia basada en la documentación de los dos servicios, no una medición en vivo de todos los proveedores de alojamiento.
| Prueba | Evidencia que debes registrar |
|---|---|
| Endpoint ya iniciado | Si una solicitud de diagnóstico que no ejecuta operaciones recibe la respuesta prevista. |
| Primera solicitud después del período de inactividad documentado | Estado de entrega del emisor y tiempo de respuesta del receptor en ese primer intento. |
| Evento aceptado | Si el receptor registra el evento de forma duradera antes de confirmarlo. |
| Resultado del procesamiento | Si la acción posterior prevista tuvo éxito o falló. |
Usa diagnósticos que no puedan colocar operaciones reales. Evita reenviar un webhook de ejecución solo para medir su velocidad. Registra un identificador seguro del evento para poder relacionar las observaciones del emisor y del receptor.
Si el diseño confirma la recepción rápidamente y procesa después, esa confirmación debe representar un paso de aceptación real y duradero. Devolver un resultado exitoso antes de registrar el evento de forma segura puede ocultar una pérdida posterior. La persona operadora también necesita visibilidad de los fallos de procesamiento; un resultado HTTP exitoso no confirma una ejecución del bróker.
Diseña deliberadamente el manejo de duplicados. TradingView documenta un comportamiento específico de reenvío ante ciertas respuestas de error del servidor. No supongas que todos los tiempos de espera agotados siguen la misma regla de reintento ni permitas que una entrega repetida cree una orden duplicada.
Render también documenta un sistema de archivos efímero para sus servicios web del plan Free. Si el receptor depende de archivos locales para registrar eventos, verifica qué ocurre después de un reinicio o una suspensión por inactividad. Elige un diseño de persistencia compatible en lugar de asumir que un archivo de desarrollo seguirá disponible.
Seguir un webhook hasta la ejecución del bróker · Explorar ingeniería de automatización de trading · Explorar herramientas TGIM.
