01
Entrega guiada por especificación e hitos
Una especificación maestra de más de 1.100 líneas con IDs de requisito y mapeo de evidencia evita construir servicios vacíos; cada hito produce un corte vertical verificable.
← Todos los proyectos
Proyecto personal
PlayerMesh — Plataforma de Identidad Global de Jugadores
Plataforma de identidad global de jugadores, Docker-first, con observabilidad integrada
Arquitectura
- Identidad, juegos y riesgo como servicios separados
- Base de datos por servicio en DynamoDB
- Outbox transaccional sobre Redpanda (Kafka)
- Sesiones en servidor mediante un BFF
- Caché y cuotas en Redis
El BFF llama a Identity Core, que revisa las cuotas de OTP en Redis, pide a Risk Service evaluar el intento y confirma la sesión y su evento de outbox con escrituras condicionales. El correo se envía de forma asíncrona (ver la vista de eventos).
- Servicio / cómputo
- Almacén de datos
- Cliente
- Síncrono
- Asíncrono / bucle
Cómo fluye, paso a paso
Haz clic en un paso para saltar a él. Haz clic en un componente para ver detalles.
Qué hace
PlayerMesh es una plataforma de identidad global de jugadores: una identidad duradera compartida entre varios juegos, con cuentas por juego, dispositivos, OTP y MFA, y cambios de cuenta sensibles. Identity Core, Game Services y un Risk Service están detrás de endpoints BFF por aplicación, persisten en DynamoDB con caché Redis y publican eventos outbox mediante Redpanda hacia un worker de plataforma. Un Control Center y un stack completo de observabilidad hacen visibles y medibles los fallos.
El problema
Los jugadores quieren una identidad duradera entre juegos y dispositivos, y los operadores necesitan seguridad, fiabilidad y visibilidad de fallos. El proyecto explora cómo modelarlo y operarlo con evidencia medible y honesta, sin paneles inventados.
Qué construí
- Identity Core gestiona OTP, sesiones, handles y el registro de vínculos con juegos; Game Services, Risk Service y un Platform Worker son dueños de sus propios datos y nunca leen tablas ajenas.
- Diseño por patrones de acceso en DynamoDB con escrituras condicionales, más un outbox transaccional que publica en Redpanda y consumidores idempotentes.
- Módulos Java con puertos y adaptadores y tests de dependencias que prohíben a identity importar clases de implementación de juegos.
- Control Center respaldado por una API de observabilidad con consultas fijas y autorizadas sobre Prometheus, Loki y Tempo, además de trazas, incidentes y experimentos de caos.
- Builds reproducibles y conscientes de la cadena de suministro: cada tag verificado para amd64 y arm64, ninguno en latest, checksum de Gradle fijado, Dockerfile multi-stage no-root cuyo build ejecuta los tests.
- Red con mínima exposición y health checks reales (ListTables a nivel de protocolo en DynamoDB, PING en Redis) en lugar de simples chequeos de puerto.
Decisiones clave y por qué
02
Pocos despliegables cohesivos, fronteras de módulo firmes
Identity, el registro de vínculos y las sesiones comparten frontera transaccional para que las verificaciones de propiedad sean atómicas, y los servicios se comunican solo mediante APIs o eventos.
03
Síncrono para autorización, asíncrono para el resto
Auditoría, notificaciones y proyecciones fluyen por Redpanda, de modo que una caída del broker retrasa proyecciones pero nunca borra cambios de jugador ya confirmados.
04
Docker-first con toolchains fijados
El host solo necesita Docker; JDK, Gradle e imágenes están fijados para que cualquiera reproduzca el mismo build y resultado de tests.
05
Observabilidad desde la base
Colector, métricas, logs y trazas existen antes de la primera integración con un juego, de modo que las afirmaciones de fiabilidad se miden en lugar de afirmarse.
Stack tecnológico
- Lenguajes
- Java 21
- Backend
- Spring Boot 4
- DevOps
- Gradle (Kotlin DSL)OpenTelemetry CollectorPrometheus / Loki / Tempo / GrafanaDocker Compose
- Frontend
- Next.js 16 / React 19Tailwind CSS 4
- Datos
- RedisDynamoDB
- Mensajería
- Redpanda (Kafka API)
- Otros
- Email provider (SMTP sink in local dev)