Architecture & Batching

Sending an HTTP request for every single button click or page view would quickly overwhelm your backend and slow down the user's browser.

To solve this, the SDK uses a highly optimized Batching & Queuing Architecture.

1. Time-Based Batching (5 Seconds)

When you call track(), the event is pushed into an in-memory queue. The SDK automatically flushes this queue to the backend in a single HTTP request every 5 seconds.

2. Overflow Protection

If a user interacts rapidly with the app (e.g., scrolling through a long list of games and firing 20 events quickly), the SDK will not wait for the 5-second timer. If the queue reaches 20 events, it flushes immediately to prevent memory bloat.

3. Page Unload Data Recovery

If a user triggers an event (like a game win) and immediately closes their browser tab, the 5-second timer might not have fired yet.

To prevent data loss, the SDK listens to native browser events:

• pagehide: Triggered when the user closes the tab or navigates away.
• visibilitychange: Triggered when the user switches tabs or backgrounds the mobile app.

When these events fire, the SDK forces an immediate flush of the queue, ensuring critical analytics data is never lost.

4. Silent Error Handling

Analytics should never crash the user's application.

If the backend analytics endpoint is down, or if a network error occurs during a flush, the SDK silently catches the error, logs a warning to the console, and drops the batch.

Frontend developers do not need to wrap track() calls in try/catch blocks.