Infraestructura

La infraestructura del Bot de Trading ByNinja está diseñada para una operación autónoma de larga duración en entornos del mundo real inestables. Los sistemas de trading de criptomonedas deben permanecer operativos 24/7, recuperarse automáticamente de fallos inesperados y minimizar el tiempo de inactividad sin requerir intervención manual.

Para lograr esto, la infraestructura incluye:

• •Bucles de ejecución Watchdog
• •Recuperación automática ante fallos
• •Orquestación de reinicio de procesos
• •Manejo de apagado graceful
• •Entorno de ejecución persistente
• •Ejecución de módulos aislados

Toda la arquitectura está construida en torno a la tolerancia a fallos y la continuidad operativa.

La capa de ejecución principal del sistema está controlada a través de un script lanzador watchdog dedicado:

./run.sh trading
./run.sh telegram

El script watchdog actúa como un supervisor de procesos ligero responsable de:

• •Validación del entorno
• •Activación del entorno virtual
• •Inicio del módulo
• •Detección de fallos
• •Manejo de reinicio automático

Este enfoque evita la necesidad de gestores de procesos externos durante el desarrollo o despliegues ligeros, al tiempo que proporciona una resiliencia de estilo de producción.

Antes de iniciar cualquier módulo, el script valida:

• •Argumentos de entrada
• •Existencia del entorno virtual
• •Configuración de tiempo de ejecución

Ejemplo:

if [[ "$MODULE" != "trading" && "$MODULE" != "telegram" ]]; then
    echo "Invalid argument"
    exit 1
fi

El script también asegura que el entorno virtual de Python exista:

if [ ! -f "$VENV_PATH" ]; then
    echo "Virtual environment not found"
    exit 1
fi

Esto previene el inicio accidental con dependencias rotas o parámetros de ejecución incorrectos.

La infraestructura activa un entorno virtual de Python dedicado antes de la ejecución:

source "./env/bin/activate"

Esto garantiza:

• •Aislamiento de dependencias
• •Versiones de paquetes estables
• •Comportamiento de ejecución reproducible
• •Separación limpia del despliegue

El lanzador también define explícitamente PYTHONPATH:

PYTHONPATH="$(pwd)/src" python3 -c "$CMD"

Esto asegura importaciones fiables independientemente del contexto actual del shell o la ubicación del despliegue.

Una de las características de infraestructura más importantes es el bucle de reinicio automático.

El lanzador monitorea continuamente el proceso del bot:

while true; do
    PYTHONPATH="$(pwd)/src" python3 -c "$CMD"
done

Si el proceso sale inesperadamente, el watchdog detecta inmediatamente el fallo y relanza el módulo automáticamente.

Lógica de detección de fallos:

EXIT_CODE=$?

if [ $EXIT_CODE -ne 0 ]; then
    echo "[CRASH] Restarting..."
    sleep $RESTART_DELAY
fi

Esto crea un modelo de ejecución autocurable capaz de recuperarse de:

• •Excepciones inesperadas
• •Fallos de red
• •Interrupciones de API
• •Bloqueos
• •Inestabilidad temporal del sistema
• •Terminación externa de procesos

La infraestructura añade intencionalmente un tiempo de enfriamiento para el reinicio:

RESTART_DELAY=3

Esto previene:

• •Bucles de reinicio rápido infinitos
• •Picos de CPU durante fallos repetidos
• •Ataques de API
• •Inundación de logs

El breve retardo da tiempo a los sistemas externos para recuperarse antes de reintentar la ejecución.

El sistema separa la infraestructura en dos servicios reiniciables de forma independiente:

Este aislamiento proporciona varias ventajas:

• •Un subsistema puede fallar independientemente
• •El monitoreo de Telegram puede permanecer en línea durante fallos de trading
• •El trading puede continuar incluso si Telegram falla
• •Depuración y mantenimiento más fáciles

Los módulos se comunican a través de la capa TCP interna en lugar del acoplamiento directo.

La infraestructura soporta un comportamiento de apagado controlado utilizando el manejo de señales.

Ejemplo:

signal.signal(signal.SIGINT, signal_handler)

Al apagar:

• •El trading se detiene de forma segura
• •La persistencia se vacía al disco
• •Las conexiones TCP se cierran limpiamente
• •Los hilos terminan gracefulmente

Ejemplo de flujo de apagado:

🛑 Shutdown signal received...
💾 Forcing save to disk...
✅ PersistentMap stopped

Esto es crítico en los sistemas de trading porque los apagados incorrectos pueden llevar a:

• •Pérdida del estado de la posición
• •Persistencia corrupta
• •Datos de recuperación inconsistentes
• •Órdenes no cerradas

La infraestructura sigue un principio simple pero poderoso:

Crash → Detect → Restart → Recover State → Continue Trading

El bot está diseñado bajo el supuesto de que los fallos son inevitables en sistemas distribuidos de larga duración.

En lugar de tratar de prevenir todos los fallos posibles, la arquitectura se centra en:

• •Detección rápida
• •Reinicio fiable
• •Recuperación de estado persistente
• •Continuidad operativa

Esto aumenta drásticamente la fiabilidad a largo plazo.

La infraestructura trabaja estrechamente con el subsistema de persistencia.

Antes del apagado o reinicio:

• •El estado de ejecución se guarda
• •Las posiciones se persisten
• •La configuración permanece intacta
• •Los metadatos de recuperación se almacenan

Después del reinicio:

• •El estado se recarga automáticamente
• •El trading se reanuda de forma segura
• •Las posiciones existentes se restauran
• •La conectividad con Telegram regresa automáticamente

Esto crea una tubería de recuperación resistente incluso después de fallos inesperados o reinicios del servidor.

El subsistema de Telegram también actúa como una capa de monitoreo operativo ligera.

Los eventos de infraestructura se reenvían directamente a Telegram:

[CRASH] Module trading exited with code 1
Restarting in 3 seconds...

Esto le da a los operadores visibilidad instantánea de:

• •Fallos
• •Reinicios
• •Apagados
• •Eventos de recuperación
• •Problemas de conectividad TCP

El resultado es una infraestructura observable de forma remota sin necesidad de paneles de monitoreo complejos.

La infraestructura de ByNinja combina varios conceptos operativos de grado de producción:

• •Bucles de ejecución Watchdog
• •Recuperación automática ante fallos
• •Manejo de apagado graceful
• •Estado de ejecución persistente
• •Aislamiento de servicios
• •Comportamiento de reinicio autocurable
• •Monitoreo remoto a través de Telegram
• •Recuperación independiente de subsistemas

Juntos, estos componentes crean una infraestructura capaz de soportar operaciones de trading autónomas continuas con una supervisión manual mínima.