Saltar a contenido

Arquitectura general

VortexPlay es una plataforma white label de casino organizada por servicios y dominios. La API es el contrato central; el front, el backoffice y las integraciones consumen o implementan ese contrato.

Vista de contexto

flowchart LR
    Player[Usuario final] --> Front[platform-front-svelte]
    Operator[Operador / agente] --> Admin[platform-backoffice]
    Front --> API[platform-api]
    Admin --> API
    API --> DB[(PostgreSQL)]
    API --> Redis[(Redis)]
    API --> Queue[[SQS / Queue]]
    Queue --> Workers[Workers y lambdas]
    Workers --> Athena[(Athena)]
    Workers --> S3[(S3)]
    Providers[Proveedores de juego] --> Integrations[blueocean / aggreg88 / lucky-spins]
    Integrations --> DB
    API <--> Providers
    Front -. WebSocket .-> BalanceWS[balance-websocket]
    BalanceWS --> Redis

Componentes

  • platform-api: API REST Laravel, autenticación Sanctum, multi-tenant por dominio, wallets, transacciones, juegos, configuración de plataforma.
  • platform-backoffice: BackOffice Filament sobre la misma base PostgreSQL. Gestiona plataformas, usuarios, reportes y configuración. Carpeta local habitual: platform-admin.
  • platform-front-svelte: frontend SvelteKit white label. Consume platform-api y aplica el tema según la plataforma.
  • Integraciones: servicios Laravel que implementan los endpoints y callbacks de cada proveedor de juego. Comparten la base de datos site con platform-api.
  • Lambdas: procesos desacoplados para reportes, exportaciones, sincronización y WebSocket de saldo.
  • platform-utils: paquete Composer compartido con modelos, repositorios, enums y contexto de plataforma.
  • satis: repositorio Composer privado para distribuir platform-utils.

Flujo de datos de alto nivel

  1. El front resuelve la plataforma por dominio y envía ?domain=<host> en cada request.
  2. platform-api identifica la plataforma con IdentifyPlatform y fija PlatformContext.
  3. Las consultas se filtran por plataforma, moneda, nivel y usuario según corresponda.
  4. Los cambios de saldo se registran como transacciones y pueden publicarse a Redis/SQS.
  5. balance-websocket entrega actualizaciones de saldo al navegador.
  6. Los reportes se alimentan de Athena a partir de exportaciones y agregados.

Principios

  • API-first: el contrato vive en platform-api/docs/api-contract.md.
  • Multi-tenant: ninguna consulta debe ignorar la plataforma.
  • Server-authoritative en slots y wallets: el cliente no decide saldos ni resultados.
  • Repositorios y formatters en Laravel: no exponer modelos directamente.
  • Configuración por entorno: secretos en AWS Secrets Manager, no en el repositorio.
  • Servicios desplegables de forma independiente: cada repo tiene su pipeline y su release.

Documentación relacionada