Proposed Direction

  - Single core language: Go for all server runtime (gateway + lobby + game logic).
  - Web/UI: TypeScript (Next.js or simple React/Vite) only.
  - Goal: Keep binary protocol compatibility via a Gateway while the Core Monolith evolves.

  ———

  Architecture (Monolith First)

  [Game Client] ⇄ [Go Gateway] ⇄ [Go Core Monolith]
                                       ├─ Lobby module
                                       ├─ Matchmaking module
                                       ├─ Game loop module
                                       └─ Data access layer

  - Gateway: speaks binary protocol; maps opcodes to internal RPC/handlers.
  - Core Monolith: simple Go service with clear module boundaries; no network protocol details here.
  - Data: Postgres + Redis (optional) behind a DAL.

  ———

  Phase 0: Baseline Observability (immediate)

  - Add request/session IDs at the lobby entrypoint.
  - Add JSON logs (opcode, account, session, latency).
  - Add packet capture/replay harness (proxy or gateway shim).

  This sets up parity testing for any rewrite.

  ———

  Phase 1: Go Gateway (binary protocol fidelity)

  - Implement binary parsing and encoding in Go.
  - Map each opcode to a handler interface.
  - For now, proxy handlers to legacy C servers (so clients keep working).

  This becomes the compatibility anchor.

  ———

  Phase 2: Go Core Monolith (first rewrite)

  - Implement core modules in Go and progressively cut traffic over.
  - Start with lobby/auth/deck APIs (lower risk).
  - Add game loop later with deterministic state checks.

  ———

  Phase 3: Data Migration

  - Introduce Postgres schemas.
  - Mirror writes (old → new), then flip reads.
  - Eventually remove Couchbase.

  ———

  Why this fits your preferences

  - Only Go + TS.
  - Monolith first with future separation if needed.
  - Fully off C while maintaining client compatibility.