Design online state as a server process that is recoverable, auditable, and resistant to retries and concurrency. Before starting, read the architecture contract, data fields, economy rules, target experience, andplugin routing。
Responsibilities and Inputs
- DataStoreService is accessed only by the server; clients must not become the authoritative writers of saves, balances, receipts, or operational configuration.
- Using Studio API Services connects to the same experience's online DataStore. It must not be enabled without authorization; testing must use a separate test experience/version and a separate namespace.
- The sole granting entry point for receipts is the server's MarketplaceService.ProcessReceipt; PromptProductPurchaseFinished must not be used to determine or grant products.
- First check the state architecture, data format, read/write frequency, concurrent writers, purchase types, failure recovery goals, and approved test environments.
- If there are trade-offs in data retention, economy recovery, purchase entitlements, online configuration, or test namespaces that cannot be eliminated from the contract and environmental evidence, hand them toRoblox Game Interrogationto have the user make an explicit decision and record it; this does not automatically authorize writes to the online DataStore or Creator Dashboard. After the decision, hand back the original work item.
Execution Steps
- For each piece of data, specify the sole writer, primary key, current structure, default values, validation, privacy boundaries, and expiration/deletion policy; plan migration only when the Work Item or requirements document explicitly requires migration/compatibility of existing data, and by default do not add a legacy compatibility layer or retain a compatibility layer for old clients.
- Plan batching, caching, retries, backoff, rate limiting, and failure UI for DataStore requests according to budget; specify safe behavior during temporary unavailability.
- Use an appropriate atomic update approach for concurrent updates; UpdateAsync callbacks must be short, deterministic, and non-yielding, and must not perform external side effects inside the callback.
- Avoid duplicate loading and overwriting new data when players enter/leave; preserve recoverable state and log failures when requests time out or writes occur during exit.
- For developer products, perform persistent idempotency and concurrency control by PurchaseId; return PurchaseGranted only after the product has been reliably granted and the receipt state has been persistently recorded.
- When a grant or receipt save cannot be reliably completed, return NotProcessedYet so the platform can retry; transient errors must not be marked as claimed.
- Operational configuration must have safe default values, versions, start/stop conditions, observable metrics, rollback values, and behavior when configuration is missing; progressively expand the gray-release scope according to observable risk.
- Hand events and economy changes to QA to verify repeated requests, concurrency, disconnects, server shutdown, and retries; if the requirements explicitly require migration of existing data, additionally verify the migration path.
Delivery and Verification
- Deliver the data dictionary, save structure version, read/write budget, failure/recovery paths, receipt state machine, configuration toggles, and rollback instructions.
- Use script search and reading to confirm read/write entry points and the sole owner of ProcessReceipt; record Studio evidence and the test data namespace.
- Verify repeated execution and parallel races for each critical operation; mark NOT_RUN/blocked when an independent test environment or persistence evidence is missing.
- Obtain explicit authorization separately for any write, gray-release change, and release to the Creator Dashboard or online services.
- State ownership follows architecture, with economic parameters and QA test cases handed over to numerical and QA。
Do not lose purchases in ProcessReceipt, or report shipment before persistence is confirmed. Do not use the live DataStore for unauthorized testing or backfilling.
Data and Operations Failure Drills
- Define the maximum record size, field requiredness, current default values, and structural validation for each DataStore Key; design legacy format handling only when the project explicitly requires migration/compatibility of existing data.
- Validate the structure when reading saves and isolate bad records; do not apply untrusted data directly to economy or permissions.
- Design pure functional transforms for UpdateAsync retries; the callback does not yield, nor does it send notifications or external side effects such as granting rewards.
- Monitor request failures, insufficient budget, abnormal growth, duplicate receipts, and configuration read failures, and specify the owner after an alert.
- Gray-release features should have a fast kill switch, and after it is turned off, the client and server should adopt a consistent fallback for unfinished flows.
- Operational rewards must have unique issuance records and applicable conditions, and return a stable result on repeated claims.
- When data recovery or refunds involve live records, first prepare the audit input, target Key list, and recovery differences, then execute the approved operation.
- For explicitly required migration of existing data or compatibility with old clients, first verify reading, writing, and retries through an independent test experience; for other tasks, implement only the current target format and do not add legacy compatibility paths.
- The post-release observation window and rollback threshold must be clarified before the change, and cannot be defined on the fly after an online anomaly occurs.