> For the complete documentation index, see [llms.txt](https://ans-dev.gitbook.io/datareplicator/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ans-dev.gitbook.io/datareplicator/information/how-it-works.md).

# How It Works

`DataReplicator` is more than just a remote wrapper; it's a comprehensive data management pipeline. Here’s a look at the core mechanics that make it work seamlessly.

<details>

<summary><strong>Secure Handshake &#x26; Obfuscation</strong></summary>

When a client first listens to a key, the server generates a unique, cryptographically secure, and random "obfuscated key" for that specific player-key pair. All future communication for that data uses this obfuscated key, making it difficult for an exploiter to guess or understand your data structure. If the data is marked as encrypted, a one-time, post-quantum key exchange is also performed to establish a secure session key.

</details>

<details>

<summary><strong>Intelligent Update Batching</strong></summary>

Calls to [`:Update()`](/datareplicator/api-reference/server-side-api/update.md) and [`:Delete()`](/datareplicator/api-reference/server-side-api/delete.md) on the server don't fire remotes immediately. Instead, all changes are intelligently queued for each player. At the very end of the current server tick (using [task.defer](https://create.roblox.com/docs/reference/engine/libraries/task#defer\\)), all queued changes are bundled into a single, compact table (a "batch") and sent in one [RemoteEvent](https://create.roblox.com/docs/reference/engine/classes/RemoteEvent) call per player. This dramatically reduces network traffic and server load.

</details>

<details>

<summary><strong>Priority &#x26; Delta Processing</strong></summary>

Before a batch is sent, the server performs two key optimizations. First, it sorts the queued data by **Priority**, ensuring critical game information is always processed first. Second, if a table is marked for **Delta Compression**, the server calculates only the changes from the last known state and sends a tiny "patch" instead of the full table, massively saving bandwidth.

</details>

<details>

<summary><strong>Secure Transport &#x26; Encryption</strong></summary>

If a piece of data is marked as encrypted, it is protected during transit using the secure session key established for that player. This makes the data content unreadable to any outside observers on the network. The entire batch, containing a mix of both plain and encrypted data, is then sent.

</details>

<details>

<summary><strong>Client-Side Processing &#x26; Caching</strong></summary>

The client receives the batch and processes each item. Encrypted data is decrypted, delta patches are applied to the local cache, and full updates overwrite existing data. The final, reconstructed data is then stored in the client's local cache for instant access via [`:GetCached()`](/datareplicator/api-reference/client-side-api/getcached.md).

</details>

<details>

<summary><strong>Signal-Based Updates</strong></summary>

After the local cache is updated, a lightweight, pure-Lua **Signal** fires for the corresponding `realKey`. Any part of your client-side code connected via [`:Listen()`](/datareplicator/api-reference/client-side-api/listen.md) is then instantly and efficiently notified of the new data, allowing your UI and game logic to react in real-time.

</details>