Yes, that is the right question. The 10K number is not the expected case for every regular player. It is more of a worst-case upper bound for high-degree / influencer-like accounts in our social graph.

For regular players, we expect the friend count to be much smaller, likely under 100, and most users would probably be under 20. For those users, using brainCloud Friends with GetSocialLeaderboard / GetMultiSocialLeaderboard should be fine.

For the exceptional high-degree accounts, we expect the number to be limited at first, probably under 50. Your shadow leaderboard suggestion makes sense to us.

To confirm, would the recommended architecture be:

Keep posting every player’s score to the main leaderboard. Tag high-degree / influencer-like accounts separately. For each tagged account, maintain a separate shadow leaderboard containing only that account’s friend scores. When a friend’s score changes, mirror that score into the relevant shadow leaderboard through Cloud Code. Use the normal global leaderboard paging APIs on the shadow leaderboard to support rank 1-50, 51-100, 101-150, etc.

A few details we would like to confirm:

Is GetGlobalLeaderboardPage on the per-influencer shadow leaderboard the intended way to support paging for these large friend lists? For rotated leaderboards, should each shadow leaderboard use the same rotation settings as the main leaderboard? Is there a practical recommended maximum number of shadow leaderboards or mirrored score writes we should design around? Would increasing maxMultipleLeaderboardScoreLimit still only be needed for the regular top-N social leaderboard path, and should that be requested through brainCloud Support?

If this is the preferred pattern, we will design the normal-player path and high-degree-player path separately instead of trying to page through up to 10K friends with GetSocialLeaderboard.

Thanks!

Added the additional details to 13660

Q1: The removed player is completely excluded from reward calculation, so if the deletion happens before the job runs, that player is never iterated over and receives no rank or rewards.
Q2: Yes, the modified score will be used. The job always reads live state. Note that whether the score actually gets modified depends on the leaderboard type (e.g., for the LOW_VALUE type, only updates if the new score is less than the existing)
Q3: No backfilling, the next joiner goes to the latest instance, not the freed spot in ^2. No loop over earlier instances (^1, ^2) ever happens. The next joiner goes to ^3 (or ^4 if ^3 is full). The freed spot in ^2 stays empty permanently.

brainCloud developers have just release several playable builds of our famous examples! See our cool features in action. Find them at https://getbraincloud.com/demos for Windows, Mac, online and mobile.