Using leaderboard reset as a scheduler of sorts

Would there be any reason not to use a leaderboard as a makeshift scheduler?

Here’s what I’m considering:

  • During InitModule, create a “cron” leaderboard with a reset schedule of */5 * * * * (every 5 minutes - just an example)
  • Register a registerLeaderboardReset callback
  • During the callback, if the leaderboard is “cron”, do some specific processing

The motivation is to schedule some processing for midnight every day to do housekeeping on data collected throughout the day. I’ve read about using some external services to call an rpc at the requested time but if I can keep the whole thing contained without Nakama, I’d prefer that.

The reason why we don’t provide scheduling out of the box is that typical workloads (like what you have described) usually are design-smells and you should reconsider the processing pipeline.

Generally speaking, you’d need to design your flow such that processing happens when a player logs in (or does an action) - rather than in the background at some point. This would ensure that processing happens only for data that is relevant when it’s relevant.

This also means that you’ll see process consumption directly relevant to player activities - and not see “noisy neighbours” issues at certain times of day when processing is happening which will imbalance resource consumption.

Fair enough. What I am looking at is basically doing a leaderboard reset, awarding prizes and setting-up the next daily competition. After poring over the tournament API docs it doesn’t appear to be a good fit, so some housekeeping must be done manually.

Processing records in a large-ish leaderboard on reset is always going to cause imbalance in resource consumptions no? Looking at the current usage of 15K records and processing being at least 2 database reads + 2 database update (1 leaderboard, 1 account), it that cause for concern?

The reason for my initial inquiry is that I’m looking to get more flexibility and control over errors than the default leaderboard reset provide. Also, having the records expire along with the leaderboard just makes it less convenient to work with those leaderboard records at a later time.

A few things for which I haven’t found in the documentation or forums:

  • What happens when a leaderboard reset errors out!? It is retried later or it is ever only called once?
  • Is there a timeout on the leaderboard reset callback? Is the system going to kill it after a certain processing time?
  • The leaderboard resets run in "mode":"leaderboard_reset" (shown by the logger in the console). What are the ramifications of that mode?

Can you tell me why this isn’t a good fit for what you are building?

Processing records in a large-ish leaderboard on reset is always going to cause imbalance in resource consumptions no? Looking at the current usage of 15K records and processing being at least 2 database reads + 2 database update (1 leaderboard, 1 account), it that cause for concern?

I can’t follow where you get those numbers from? Also if I recall correctly, Nakama (Enterprise) will automatically balance the workload across the nodes, and also a bunch of the work is done in memory.

  • What happens when a leaderboard reset errors out!? It is retried later or it is ever only called once?

That’s a really good question - @zyro can you provide info here, and @Sean can we add this to docs, please?

  • Is there a timeout on the leaderboard reset callback? Is the system going to kill it after a certain processing time?

No there is no timeout on this call.

  • The leaderboard resets run in "mode":"leaderboard_reset" (shown by the logger in the console). What are the ramifications of that mode?

There are no ramifications - this is mostly for informative purposes if you have code that only need to run under certain conditions (like if you have a shared function that you’d like to only activate part of the codepath based on a particular mode).

Thanks for the update.

The database writes/read are likely incorrect. I meant to talk about api calls. It is taken from the implemented reset routine for our daily events: a couple of get/list operations and a couple of set/write ones.

Concerning the tournaments, here is the feature evaluation I did:

  • optional requested join: this is not needed, anyone/everyone can participate. Did not find value in joining as a separate step
  • max score attempts: in our case, for a single game/attempt, there can be a variable number of score submission, so it doesn’t match the use case (it is a mobile game with autosave of the score every 90s)
  • start date / end date: instead of using dates, our events are broken by season and day. There could be a conversion between season/day and startTime/endTime but there is nothing gained from this

A further note on the automatic leaderboard reset/expire: I am not sure what is gained with this feature. It makes the querying of the records more finicky since we must now handle dates. Also, I understand that once created this cannot be changed? In addition to possible runtime errors, I like the flexibility of processing the records as desired in case of problems. This has happened in the past and often sadly: after removing a cheater’s records, we would need to reprocess the event to update the rewards.

I hope this makes sense.

In case it might be useful, here is a brief description of the system I’m porting:

  • a league season that last 28 days
  • each day there is an open competition on one specific game level with special rules
  • doing well in the daily event rewards points toward the season’s total
  • depending on the special rules, the player can play 2 to 5 times in order to get the best possible score
    • Scoring is submitted during a game as a safety measure against bad network connections (it is a mobile game, so background score posting every 90s)
  • rewards for playing in the events