Projects

Project Details

Apogee — Game Backend Platform 2026

Apogee architecture: players flow through matchmaker and allocator to gameserver pods, whose events stream through NATS JetStream and the ingest service into Parquet on S3 and Postgres rollups, feeding deterministic replay

Project Overview

Apogee is a game backend platform built in Go. The game itself — a headless, deterministic, tick-based arena — is deliberately trivial; the real work is everything around it: skill-based matchmaking, session allocation on Kubernetes, a streaming telemetry pipeline, live-ops configuration, deterministic replay, and synthetic load generation.

All seven services are implemented and deploy to a local k3d cluster with a single make k3d-up, where a smoke target drives the full path end to end: enqueue → match → allocate → play → telemetry. Every significant technical decision is recorded as an Architecture Decision Record.


The Seven Services

Each service is a thin cmd/<name> binary that embeds a shared observability runtime and delegates its real work to a domain package under internal/.

  • gameserver: Runs the deterministic tick-based arena simulation for a match — same inputs, same seed, same outcome, every time.
  • matchmaker: Skill-based, region-aware queueing and match formation.
  • allocator: Schedules game server pods onto Kubernetes to meet demand.
  • ingest: Telemetry pipeline consuming NATS JetStream into Parquet files on S3 plus rollup tables in Postgres.
  • configsvc: Remote config and feature flags with player segmentation for live-ops.
  • replay: Re-runs recorded inputs deterministically, with snapshot-accelerated seeking for the scrubber UI.
  • loadgen: Simulates tens of thousands of synthetic concurrent players to exercise the whole platform.

Cross-cutting concerns live in a shared internal/obs runtime: structured slog logging, a private Prometheus registry, OpenTelemetry tracing exported to Jaeger, and an admin HTTP server with liveness, readiness, and metrics endpoints. Persistence is a shared layer on pgx + sqlc + goose with Redis, configured 12-factor style via environment variables.


Deployment — Two Environments, Deliberately Different

Local (k3d) — fast imperative inner loop

ArgoCD manages the Helm dependencies (Postgres, Redis, NATS, MinIO, Jaeger, a trimmed kube-prometheus-stack), while the Apogee services are applied imperatively from kustomize overlays with locally built images imported into the cluster. This is deliberately not GitOps for the services — local GitOps would fight the build → import → restart inner loop, and the trade-off is documented in an ADR.

Cloud — full app-of-apps GitOps

A single ArgoCD root application reconciles everything from git: dependencies, the observability stack, ArgoCD itself, and the services from images pushed to GHCR by CI. The cloud overlay renders 53 resources and diffs cleanly; Terraform modules for the cloud infrastructure are written and version-controlled.

The README is explicit about what is proven versus not — working platform at laptop scale, GitOps plumbing verified by rendering and diffing rather than claimed — a deliberate practice of not over-claiming in a demo.


Engineering Practices

  • Architecture Decision Records: Eleven MADR-format ADRs covering deterministic simulation, the rating system, live-ops config, session allocation, replay storage, load generation, pprof exposure, deploy strategy, and load-test measurement validity.
  • Determinism as a foundation: The simulation is tick-based and fully deterministic, which is what makes replay a storage problem (record inputs, not video) and makes load-test results reproducible.
  • Observability by default: Every service ships Prometheus metrics, OpenTelemetry traces, and health/readiness probes from day one via the shared runtime, with Grafana dashboards provisioned locally.
  • Type-safe persistence: sqlc-generated queries over pgx with goose migrations, so SQL is checked at generation time rather than discovered broken at runtime.
  • Verified end to end: A smoke target drives the full enqueue → match → allocate → play → telemetry path against the running cluster; the Go test suite runs with the race detector.

Project Information

Role

Solo Developer

Type

Distributed Systems / Platform Engineering

Backend

Go 1.26, PostgreSQL 16 (pgx + sqlc + goose), Redis 7, NATS JetStream, MinIO/S3 + Parquet

Infrastructure

Kubernetes (k3d), kustomize, ArgoCD, Terraform, Docker, GitHub Actions

Observability

Prometheus, Grafana, OpenTelemetry, Jaeger

Frontend

Vite + React + TypeScript replay scrubber

Links
GitHub Repository