Cuando hay premio, aparece el que hace trampa
El problema
Una aplicación de pronósticos suena simple: el usuario dice cómo va a salir cada partido, se acumulan puntos, hay un ranking.
Lo que la vuelve difícil es el premio. En el momento en que el primer puesto vale algo, aparece quien se abre veinte cuentas y quien automatiza sus pronósticos. Y el problema no es sólo que ganen: es que si el ranking no es confiable, la aplicación entera deja de tener sentido para el que juega en serio.
Qué construí
Una plataforma con pronósticos por partido, puntaje, ranking global y un panel administrativo para cargar partidos, resolver resultados y gestionar premios.
Está armada en capas separadas —dominio, casos de uso, infraestructura y API en proyectos distintos—, de modo que las reglas del juego no dependen de la base de datos ni del framework web.
Las decisiones que costaron
Detectar no es castigar. Es la decisión que más forma le dio al sistema. Detectar multicuenta con señales indirectas —el mismo dispositivo, el mismo comportamiento, la misma ráfaga de pronósticos— se equivoca. A veces son dos hermanos en la misma casa. Si la detección banea sola y de forma definitiva, cada error es una persona real expulsada sin recurso.
Entonces la detección agrupa y marca, y hay un proceso de apelación con un administrador que decide.
Qué pasa cuando el sistema sospecha
- Señal Se marca, no se expulsa Las cuentas que se parecen quedan agrupadas y marcadas. La persona sigue jugando.
- Escalón La sanción sube de a poco Primero un límite, después una pausa. La medida más dura no es la primera.
- Recurso Siempre hay apelación Se abre con un enlace propio, sin necesidad de entrar a la cuenta — que es justo lo que la persona no puede hacer. Un administrador resuelve.
La apelación no requiere iniciar sesión. Suena a detalle y es lo que hace que el recurso exista de verdad. Si para apelar hay que entrar a la cuenta, y la cuenta está bloqueada, no hay apelación: hay un formulario decorativo. Se abre con un enlace propio, independiente de la sesión.
El límite de peticiones se cuenta por combinación, no por IP. Contar por IP castiga a todos los que salen por la misma conexión —una oficina, una escuela, un pueblo con un solo proveedor— y no frena al que rota direcciones. La clave del límite combina varias señales.
Se probó mucho, y por un motivo concreto. Hay unos 2500 tests en el backend y 1500 en el frontend. No es prolijidad: en una aplicación con ranking y premios, un error de puntaje le saca a alguien algo que se ganó, y cuando se detecta ya es tarde para arreglarlo sin discutir con una persona.
Vista ilustrativa · datos de ejemplo
Grupo detectado · 4 cuentas
| Cuenta | Señal | Aciertos | Estado |
|---|---|---|---|
| usuario_a | dispositivo compartido | 18 | Marcada |
| usuario_b | dispositivo compartido | 17 | Marcada |
| usuario_c | ráfaga · 40 en 2 min | 19 | Pausada |
| usuario_d | dispositivo compartido | 3 | Sin acción |
Ninguna de las cuatro está expulsada. El sistema agrupó y marcó; la decisión no es suya.
Apelación abierta
usuario_c · hace 2 h
«Somos dos hermanos, jugamos desde la misma computadora.»
MantenerLevantar
Resultado
El juego funciona con ranking y premios, y la parte antifraude tiene detección, agrupación, sanción escalonada y apelación. Está en desarrollo activo: falta la revisión legal de términos y privacidad antes de abrirlo al público.