Skip to content

Data Infrastructure

This system handles all data-related operations, including database access and communication between servers.

When to use

  • You need to store or retrieve data
  • You want to communicate between servers
  • You work with persistent or shared data

MySQL (MariaDB)

We use MariaDB with HikariCP for connection pooling.

  • Always use try-with-resources for connections/statements
  • Never run queries on the main thread
  • Use prepared statements (no string concatenation)
  • Connections are managed via Hikari (do NOT create your own)
  • Different users may exist for different services/systems

Topics

  • [[Naming & Database Conventions|Core-API/Data-Infrastructure/MySQL/Naming-&-Database-Conventions]]
  • [[Base Execution|Core-API/Data-Infrastructure/MySQL/Base-Execution]]
  • [[Delayed Queries|Core-API/Data-Infrastructure/MySQL/Delayed-Queries]]
  • [[Table Creation|Core-API/Data-Infrastructure/MySQL/Table-Creation]]

Redis

[!important]

Redis is only used as a second-layer cache. NEVER store persistent data here. The Redis disk gets wiped on every network restart (at least once per day).

We use Redis with Jedis and connection pooling.

  • Always use pooled connections (do NOT create new ones manually)
  • Never block threads with long Redis operations
  • Use Redis for:
  • fast data access
  • cross-server communication
  • Do NOT use Redis as a primary database replacement

Topics

  • [[Base Execution|Core-API/Data-Infrastructure/Redis/Base-Execution]]
  • [[Packet|Core-API/Data-Infrastructure/Redis/Packet]]
  • [[Packet Listener|Core-API/Data-Infrastructure/Redis/Packet-Listener]]
  • [[Subscriber|Core-API/Data-Infrastructure/Redis/Subscriber]]

Common pitfalls

  • Running database queries on the main thread
  • Writing inefficient or unoptimized queries
  • Mixing MySQL and Redis responsibilities
  • Implementing custom data handling outside the core