Saltar a contenido

Flujos de datos

Autenticación

sequenceDiagram
    participant F as Front
    participant A as platform-api
    participant DB as PostgreSQL
    F->>A: POST /api/auth/login + domain
    A->>DB: Validar usuario y plataforma
    A-->>F: data.token (Sanctum)
    F->>A: Requests con Authorization: Bearer <token>

El token se envía en cada request. Un 401 implica cerrar sesión y redirigir al login.

Lanzamiento de juego

  1. El front solicita la URL de lanzamiento a platform-api.
  2. La API valida usuario, plataforma, moneda, nivel y proveedor.
  3. La integración correspondiente genera la sesión firmada con el proveedor.
  4. El front abre el juego en iframe o embed.
  5. Los callbacks del proveedor llegan a la integración y actualizan wallet/transacciones.

Wallet y transacciones

  • Cada usuario tiene una wallet por moneda.
  • Créditos y débitos se registran como transacciones.
  • Nunca se expone el modelo directamente: se usa un formatter.
  • El saldo se puede publicar a Redis/SQS para actualizar el front en tiempo real.
  • balance-websocket lee la conexión activa desde Redis y envía balance.updated.

Reportes

flowchart LR
    DB[(PostgreSQL)] --> Export[tickets-data-export / users-sync]
    Export --> S3[(S3)]
    S3 --> Athena[(Athena)]
    Athena --> Stats[summary-stats]
    Stats --> S3
    Athena --> Admin[platform-backoffice]
  • tickets-data-export exporta tickets a S3 y repara tablas de Athena.
  • users-sync sincroniza usuarios.
  • summary-stats genera agregados horarios.
  • platform-backoffice consulta Athena para reportes.

Convenciones de datos

  • Fechas: ISO-8601 para timestamps; d-m-Y H:i:s para transacciones en la zona del usuario.
  • Dinero: strings con dos decimales.
  • JSON: claves en snake_case.
  • Nunca devolver password, tokens ni columnas internas.