Skip to content

[FEAT] Implement caching for Minecraft Accounts to reduce database load#205

Open
zonary123 wants to merge 2 commits intohypherionmc:universalfrom
zonary123:universal
Open

[FEAT] Implement caching for Minecraft Accounts to reduce database load#205
zonary123 wants to merge 2 commits intohypherionmc:universalfrom
zonary123:universal

Conversation

@zonary123
Copy link

Performance Improvements with Caching

A while ago I noticed a Spark report showing performance issues in SDLink caused by frequent player-data requests to the database.
To improve this, I implemented a caching system to reduce the number of unnecessary database queries.

I haven’t run tests yet, but after reviewing the code, this change should not cause any issues related to synchronization or data handling.

Additionally, I integrated Caffeine so the cache can automatically remove entries after they haven’t been used for a certain amount of time.

image

@hypherionmc
Copy link
Owner

hypherionmc commented Nov 24, 2025

Hey.

Thanks for the PR. This is something I was planning to do in the rewrite.

My only concern here is that we could be holding on to accounts, when they've been unlinked (access control).

So people could potentially have access to the server for longer than they should.

So this will definitely need some testing before we can merge it.

Edit: the same goes for when people actually verify. It could cause delays because the cache hasn't been updated.

So to address this, we should probably forcefully update the cache when an account is linked and unlinked

@zonary123
Copy link
Author

Hey,

Thanks for the feedback! I understand your concern about holding onto accounts after they've been unlinked, as well as the potential delays when verifying accounts due to outdated cache.

The main idea behind using Caffeine is to manage cache retention efficiently. We've defined flexible expiration rules, such as:

  • Access-based expiration: If a cache entry isn't accessed within a certain period (e.g., 5 seconds), it's automatically removed.
  • Write-based expiration: If an entry has been in the cache for a defined duration (e.g., 5 minutes), it expires regardless of access.

This way, we ensure that the cache isn't holding onto stale data and queries to the database are made periodically instead of on every method call. However, for critical operations like linking or unlinking accounts, we can definitely force a cache update to avoid the issues you mentioned, ensuring that the cache always reflects the most recent state.

While further testing would be important to ensure complete consistency, I don’t foresee any major consistency issues. The goal of this implementation is to strike a balance between cache performance and ensuring data accuracy without unnecessary database calls.

Let me know if you think we should adjust anything further for specific use cases!

@hypherionmc
Copy link
Owner

That's the thing, during account linking and unlinking, the data is accessed enough times in that short timespan that the cache can hold onto it.

Take this example:

I try to login to the server, but it requires me to verify my account (read 1/write 1). I get the prompt to verify, so I go into discord and verify myself (read 2/write 2). I now try to login to the server again (read 3), but it was quicker than 5 seconds since I verified, and now it tells me again that I need to verify.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants