01
Spec-first, milestone-gated delivery
A 1,100-line master spec with stable requirement IDs and evidence mapping prevents building empty services; each milestone produces a verifiable vertical slice.
← All projects
Personal project
PlayerMesh — Global Player Identity Platform
Docker-first global player identity platform with built-in observability
Architecture
- Identity, games and risk as separate services
- Database-per-service on DynamoDB
- Transactional outbox over Redpanda (Kafka)
- Server-side sessions through a BFF
- Redis cache and quotas
The BFF calls Identity Core, which checks OTP quotas in Redis, asks Risk Service to assess the attempt, and commits the session and its outbox event with conditional writes. The email is sent asynchronously (see the events view).
- Service / compute
- Data store
- Client
- Synchronous
- Async / loop
How it flows, step by step
Click a step to jump to it. Click a component for details.
What it does
PlayerMesh is a global player identity platform: one durable identity shared across multiple games, with per-game accounts, devices, OTP and MFA, and security-sensitive account changes. Identity Core, Game Services and a Risk Service sit behind per-app BFF endpoints, persist to DynamoDB with Redis caching, and publish outbox events through Redpanda to a platform worker. A Control Center and a full observability stack make failures visible and measurable.
The problem
Players want one durable identity across games and devices, while operators need safety, reliability and visibility into failures. The project explores how to model and operate that with honest, measurable evidence rather than invented dashboards.
What I built
- Identity Core owns OTP, sessions, handle claims and the game-link registry; Game Services, Risk Service and a Platform Worker each own their own data and never read another service's tables.
- DynamoDB access-pattern design with conditional writes, plus a transactional outbox publishing to Redpanda and idempotent consumers.
- Ports-and-adapters Java modules with dependency tests that forbid identity from importing game implementation classes.
- Control Center backed by an Observability API with fixed, authorized queries over Prometheus, Loki and Tempo, plus traces, incidents and chaos experiments.
- Reproducible, supply-chain-conscious builds: every image tag verified for amd64 and arm64, none on latest, pinned Gradle checksum, non-root multi-stage Dockerfile whose build stage runs the tests.
- Least-exposure networking and real health checks (wire-level DynamoDB ListTables, Redis PING) instead of simple port checks.
Key decisions and why
02
Few cohesive deployables, strong module boundaries
Identity, game-link registry and sessions share a transaction boundary so ownership checks are atomic, while services communicate only through APIs or events.
03
Synchronous for authorization, asynchronous for everything else
Audit, notifications and projections flow through Redpanda, so a broker outage delays projections but never erases already-committed player changes.
04
Docker-first with pinned toolchains
The host only needs Docker; JDK, Gradle and images are pinned so anyone can reproduce the same build and test result.
05
Observability from the foundation
Collector, metrics, logs and traces exist before the first game integration, so reliability claims are measured rather than asserted.
Tech stack
- Languages
- Java 21
- Backend
- Spring Boot 4
- DevOps
- Gradle (Kotlin DSL)OpenTelemetry CollectorPrometheus / Loki / Tempo / GrafanaDocker Compose
- Frontend
- Next.js 16 / React 19Tailwind CSS 4
- Data
- RedisDynamoDB
- Messaging
- Redpanda (Kafka API)
- Other
- Email provider (SMTP sink in local dev)