\*\*I built a centralized data orchestration engine for distributed Minecraft networks — here's the architecture\*\*



Hey !



I've been working on a side project called \*\*Nexus Core\*\* — a standalone Java application that acts as the central data layer for a multi-server Minecraft network. Instead of every Spigot server holding its own MongoDB connection pool and managing its own stale cache, all data operations are routed through Nexus Core via a Redis pub/sub message bus.



\*\*The problem it solves\*\*



In a typical Minecraft network with 10+ servers, each server independently connects to MongoDB, maintains its own in-memory cache, and duplicates the same data logic. This creates three real problems at scale: connection pool exhaustion, cache incoherency across servers, and duplicated business logic that's painful to maintain.



\*\*How it works\*\*



Spigot servers publish a JSON packet to a Redis channel:

\`\`\`json

{

  "protocol": 100,

  "source": "pvp-1",

  "type": "GET\_DATA",

  "data": { "uuid": "550e8400..." }

}

\`\`\`

Nexus Core subscribes to that channel, routes the packet to the correct \`DataAddon\` via a protocol registry (essentially a \`Map<Integer, DataAddon>\`), checks Redis cache first, falls back to MongoDB on a miss, writes back to cache, then publishes the response to the source server's channel.



\*\*The addon system\*\*



The interesting part is the \`DataAddon\` abstraction. Each addon maps to exactly one MongoDB collection and one Redis key namespace. Fields are annotated with \`@DbDataModels\` — Nexus Core discovers the schema at runtime via reflection and handles all CRUD automatically. You extend the class, annotate your fields, register the addon, and you're done:



\`\`\`java

u/DbDataModels(isId = true)

private String uuid;



u/DbDataModels(defaultValue = "0", isId = false)

private int kills;

\`\`\`



You also get a \`handleRequest()\` interceptor that lets you reject or gate operations before they hit the database — useful for permission checks or rate limiting at the data layer.



\*\*Redis key strategy\*\*



Keys follow \`{cacheKeyHeaderTag}:{idFieldValue}\` — e.g. \`stats:550e8400...\`. Cache entries are invalidated on SET and DELETE operations. GET\_ALL bypasses cache entirely since bulk result sets aren't worth caching in this context.



\*\*Monitoring\*\*



There's a live Swing dashboard built entirely with Java2D (no external UI libs) showing JVM CPU, process RAM, cached object count, and active addon count with scrolling line graphs.



Repo: [https://github.com/mustafabinguldev/nexus-core](https://github.com/mustafabinguldev/nexus-core)



Happy to discuss the architecture decisions — particularly around the Redis pub/sub model vs. a direct TCP socket approach, which I considered and rejected early on.

GitHub - mustafabinguldev/nexus-core: The central brain between your distributed Minecraft infrastructure and your persistent data layer