Roblox Server Data

TabooHarmony/roblox-brain/skills/core/roblox-server-data

by TabooHarmony38826be57ee37bcf023e9c2b85681bea3909281cNo licenseListed Oct 9, 2026Updated Oct 9, 2026

Use for Roblox server or cross-server data: OrderedDataStore leaderboards, MessagingService, world state, seasons, or guilds.

Instructions onlySoftware Development
AI-generated overview

Reference guidance for Roblox server and cross-server data: leaderboards, messaging, shared state, and temporary coordination.

What it does
Provides reference instructions for working with Roblox server-side and cross-server data. It covers OrderedDataStore leaderboards, MessagingService cross-server messaging, GlobalDataStore shared state, MemoryStoreService temporary coordination, cross-server patterns, user identity, and common pitfalls. It produces guidance rather than scripts or files.
When to use it
Use when implementing or debugging Roblox leaderboards, cross-server messaging, shared world state, seasons, or guilds. It is not intended for player persistence or Open Cloud work.
Requirements
No scripts or packages; it is instructions only. It references Roblox engine documentation and assumes a Roblox development context.

Roblox Server & Shared Data

When to Load

Load for leaderboards, messaging, MemoryStore coordination, world state, seasons, or guilds. Player persistence: roblox-data; Open Cloud: roblox-cloud.

Quick Reference

OrderedDataStore (Leaderboards)

  • Sortable DataStore. Keys are strings (tostring(UserId)); values are integers used for sorting.
  • GetSortedAsync(ascending, pageSize, minValue, maxValue) → sorted pages
  • BatchGetAsync(keys): multi-key read, ordered stores only; missing keys are omitted
  • Budget: poll GetRequestBudgetForRequestType(OrderedWrite) before bursts (per server: 30 + numPlayers x 5 writes/min)
  • For leaderboards only, never for player saves
  • Keep the user ID a static substring in keys (player_<UserId>) so RTBF templates match; hashed keys make erasure manual

MessagingService (Cross-Server)

  • SubscribeAsync / PublishAsync; no delivery or ordering guarantee, so design for idempotency.
  • Request/response: {reqId} correlation, ack on the topic, timeout. No ack ≠ not executed — replay the same reqId, don't double-grant.

GlobalDataStore (Shared State)

  • Persistent non-player state (guilds, seasons, counters). Use UpdateAsync; never for player session data.

MemoryStoreService (Temporary Coordination)

  • Queues and sorted maps for expiring matchmaking, leases, coordination.
  • Remove a read batch only after successful, idempotent processing.
  • Sorted-map paging: last item's {key, sortKey} = next exclusive bound.

Cross-Server Patterns

  • Register servers with expiring heartbeats; use MessagingService for notifications.

User Identity

  • New code identifies users with player.User (User.Id, DomainType, DomainId); UserId stays valid. Domain IDs are per-experience, so keep cross-server keys on UserId and never mix the two.

Pitfalls

  • MessagingService: fire-and-forget, unordered, cross-server latency; not for time-critical work
  • GlobalDataStore: same rate limits as player DataStores
  • Never store Instances; serialize to primitives first; SetAsync overwrites — use UpdateAsync for shared counters

Store selection and workflows: references/full.md [blocked]

Source and attribution

Source:TabooHarmony/roblox-braininskills/core/roblox-server-dataat commit38826be

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal