Thanks, that makes sense.

So our takeaway is that brainCloud Friends has no hard-coded friend limit, but very large friend lists can still have performance implications because friend IDs are stored in the UserProfile.

Also, since GetSocialLeaderboard returns all friends and does not support page-based access, it seems risky for us to allow very large mutual friend counts if we want to use Friends-based leaderboards for normal users.

We will discuss internally whether we should enforce product-level limits on following/follower or mutual friend counts, and reserve special handling, such as shadow leaderboards, for high-degree or influencer-like accounts.

Thanks again for the detailed guidance!

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.