What Flux Is Not

Flux removes the need for a separate server-side layer whose only job is distributing state to your frontend — the caching and pub/sub work that would otherwise exist purely to get data in front of a browser faster. It does not replace the infrastructure your backend uses for its own purposes: distributed locks between server processes, background job queues, or server-side session storage. Those systems solve problems that exist entirely on your server, independent of whether a browser is even involved, and Flux has no opinion about them.

Every mechanism described in these docs — the offline queue, the replay engine, the realtime adapters — operates between a browser and your API. None of it is a transport for service-to-service traffic, and none of it should be reached for when two backend systems need to talk to each other. That's a different problem with different tools.

The shaping behavior described in core-concepts/mutation-pipeline — deduplication, debouncing, coalescing — exists to stop your own UI from generating more requests than a user actually intended. It has no opinion about, and no effect on, a request made directly against your API by something other than your app's UI. Rate limiting, abuse prevention, and DDoS protection are server-side concerns and need to be enforced there, regardless of anything Flux does on the client.

Anything that moves real money — a wire transfer, a direct debit, a balance-affecting write — needs to be synchronous and needs to be handled by your actual payment infrastructure, never queued for later replay. See the fintech boundary called out in core-concepts/mutation-pipeline for the specific configuration to use on endpoints like this. Flux is well suited to the surrounding UI — saved payment methods, preference toggles, non-ledger account details — just never the ledger write itself.

Flux's multi-tenant scoping isolates one logged-in user's cached data, queued writes, and tracked jobs from another user's, on the same shared browser. It does this entirely by namespacing client-side storage against whatever user identity your app tells it about — it has no concept of login, no session validation, and no way to confirm that identity is genuine. Confirming who someone actually is remains entirely your server's responsibility, exactly as it would be without Flux in the stack at all.