Reflex state synchronization limits for high-frequency updates

Answer

Reflex does not publish a hard maximum update frequency. Latency increases as handler execution time, delta payload size, and event‑loop load grow; any “safe Hz” figure is unverified.

Concurrent event handlers

Reflex relies on ordinary Python assignment: the last completed write wins. Non‑atomic read‑modify‑write sequences can lose updates, so there is no built‑in merge or conflict resolution.

To avoid lost updates, protect critical sections with an asyncio.Lock or funnel mutations through a single handler/queue. For derived values, use Reflex computed vars instead of letting multiple handlers write the same variable.

Verification steps for your installation:

1. Pin the Reflex version and consult its release notes for any version‑specific sync behavior.
2. Create a minimal state (e.g., an integer) and an async handler that awaits briefly then increments.
3. Trigger events at increasing rates from one client and record server receive time, handler completion, and client delta arrival.
4. Run two concurrent handlers that read‑modify‑write the same variable with an await between read and write; compare the final value against a locked version to detect lost updates.
5. During the test, measure event‑loop responsiveness and WebSocket frame sizes; if handler time or frame size dominates, simplify state shape before changing transport.

Please provide the average handler execution time you observe under load so the recommendation can be refined if throttling or locking is needed.