Vise keeps a multi-server PvP platform coherent: immediate gameplay state, shared cross-server services, durable player records, and the telemetry needed to operate it with confidence.
The difficult part is not incrementing a win counter. It is making that update fast on one server, visible on every server, durable across restarts, observable in production, and available to approved integrations without exposing the storage layer.
Each chapter activates one part of the production path.
Every Paper instance identifies its region and server number, then loads the same modular core. Players can move between services while shared infrastructure keeps their network identity intact.
vise.network → EU-1 / NA-1 / D-2
Global chat is published as JSON to a shared Redis channel. Every other server receives the event asynchronously, rejects local echoes, sanitizes the payload, and renders it for its own players.
chat:globalPUBLISH chat:global {server, uuid, message}
A player event updates the in-process object first. Redis receives a self-expiring cache entry and atomic leaderboard score. MariaDB receives the authoritative profile and statistics through a pooled, prepared upsert.
memory → SETEX / ZADD → SQL UPSERT
Each instance samples TPS, players, worlds, chunks, JVM memory, threads, garbage collection, uptime, OS, and architecture. The latest snapshot powers quick checks while a Redis stream preserves roughly 24 hours of history.
server:<name>:health:latest + :stream
Redis operations are retried before being marked unhealthy. Subscribers reconnect. Database connections are pooled. Scheduled restarts warn players before a clean shutdown, and module teardown closes listeners and storage clients deliberately.
detect → retry → recover → report
Game features and external services meet the core at a controlled boundary. Tier data is fetched in parallel, Discord linking uses a five-minute one-time challenge, and tournament operations stay behind validated commands.
approved client → Vise Core → private storage
match: Q6A20QPI
ConcurrentHashMap
pooled + TLS
HikariCP + prepared SQL
Infrastructure is only trustworthy when its state is visible. Vise emits a fresh operational snapshot every five seconds and keeps enough history to investigate the shape of a bad hour, not just its final moment.
Active player objects remain in memory, so a hot path does not wait on a remote database before the game can continue.
immediate readsRedis handles cross-instance data, expiring challenges, leaderboards, event fan-out, and short-lived operational history.
pooled + expiringMariaDB stores the records that must survive process exits: identities, profiles, statistics, links, and ranked history.
prepared + durableFive-second fleet samples make capacity, stalls, memory pressure, uptime, and instance freshness visible during operation.
latest + historyPlayers see continuous identity, statistics, chat, ranks, matches, parties, and tournaments. Operators see isolated instances, explicit persistence layers, recoverable dependencies, and measurable health.