Del cuaderno a la nube: plataforma para controlar ~3,500 máquinas tragamonedas
Un casino registraba cada corte de sus máquinas a mano, en hojas de cuaderno: ID de máquina, ubicación, quién hizo el corte, el monto, el día y las ganancias. Consolidar esos datos era lento, los errores de captura eran inevitables y no había forma sencilla de auditar quién hizo qué. Con mi equipo estamos construyendo una plataforma en la nube que captura esa información de forma digital y trazable.
Mi rol
Infraestructura y administración de sistemas. El backend y el frontend los desarrolla el resto del equipo.
- Provisioning de la VM y de la red (red virtual, subnets, gateways) en la nube
- Instalación y actualización del runtime: Java 21 y Tomcat 11
- Usuarios y permisos en Linux; firewall de host con iptables
- Base de datos: usuarios con mínimo privilegio, certificados mTLS y allowlist de IPs
- Despliegue de artefactos WAR y diagnóstico de fallas
Qué registra la plataforma
- ID de cada máquina
- Ubicación dentro del casino
- Responsable del corte
- Monto, fecha y ganancias
Resultado buscado: captura en tiempo real, menos error humano y trazabilidad completa.
Arquitectura
Decisiones de diseño
Simple a propósito
Una VM y una base de datos gestionada, dentro de la capa gratuita del proveedor. El diseño contempla tres VMs (app, workers y websocket); hoy corre una y las otras se agregan cuando el proyecto escale.
Producción separada de desarrollo
Evaluamos montar la BD dentro de la VM contra usar una base de datos administrada. Elegimos la administrada para producción, por los backups gestionados y el aislamiento de fallos, y una BD en contenedor solo en localhost para desarrollo, sin exposición a internet.
Seguridad por capas
Subnets pública y privada, reglas de firewall de red con ingress mínimo, firewall persistente en el host, conexión a la BD con mTLS, acceso restringido por IP y usuarios de BD con el mínimo privilegio.
Problemas que resolví
La app no podía abrir los certificados mTLS de la base de datos. Los certificados eran propiedad de un usuario distinto al que ejecuta el servicio (tomcat), y el driver reporta ese problema de permisos, de forma engañosa, como un archivo inexistente. Solución: corregir el dueño y los permisos de los certificados para el usuario del servicio.
El WAR se desplegaba sin error visible, pero la app no respondía. Eran dos incompatibilidades apiladas: Spring Framework 7 requiere Servlet 6.1 (Tomcat 11) y el servidor tenía Tomcat 10.1 (Servlet 6.0); además, el bytecode compilado con Java 21 no lo podía leer la JVM 17 instalada. La pista: un arranque real de Spring toma ~10 s, no 2. Solución: actualizar a Tomcat 11 y Java 21.
Stack
Impacto
Captura digital
Los cortes dejan el cuaderno y se registran en un sistema central.
Trazabilidad
Cada corte queda ligado a una máquina, una ubicación y un responsable.
Menos error humano
La captura en tiempo real elimina la transcripción de cuadernos a hojas de cálculo.
Cliente 100% satisfecho con el trabajo realizado hasta ahora. Estamos midiendo el antes y el después (tiempo por corte, errores de captura y tiempo de consolidación) para publicar cifras reales.