Data Movement

STRAX generates and operates the synchronisation: change capture, movement into the hub, delivery outward, safe pausing and throughput limits.

From description to running synchronisation

Once a system is mapped, STRAX generates and operates everything needed to move its data. There is no integration code for your team to write, deploy or maintain. The platform captures changes as they happen at the source, carries them into the hub, and delivers them onward to every system that subscribes to the same canonical data.

Movement is continuous and incremental. When a Demo ISP agent updates a customer's address in Splynx, that one change reaches the hub and flows out to HubSpot and Zendesk shortly afterwards. Whole tables are not re-copied on a schedule; only what changed moves. A one-time initial load establishes the baseline when a system first joins, and from then on the systems simply stay in step.

Delivery is dependable. Changes are applied in a safe, consistent order, and a temporary outage on either side defers delivery rather than losing it.

Pausing safely

Real estates have maintenance windows, migrations and incidents, so every system carries its own movement controls. You can pause the flow to the hub, pause write-back to the source, or both, independently and per system.

The controls are designed so the safe option is the easy one. A paused system keeps recording its changes, and when you resume, everything made during the pause flows through in order. Nothing is lost and nothing needs re-loading. The console shows how much is waiting, every change of state requires a confirmation that spells out its consequence, and each is recorded in the audit trail with who acted and why.

This turns a risky operational moment into a routine one. Demo ISP can take Splynx down for an upgrade on a Saturday, pause its movement first, and resume on Sunday knowing the weekend's changes will catch up on their own.

Throughput limits protect the source

The fastest possible synchronisation is rarely the right one. A production billing database has its own users to serve, and a SaaS API will start refusing calls once its published rate limit is exceeded. STRAX therefore lets you control, per system, how fast data moves.

Limits can be adjusted when conditions change, and the console shows each system's recent throughput alongside its limit. A busy source is never overwhelmed, and a backlog clears at a controlled pace rather than in one damaging surge.

What you observe

Movement is visible, not assumed. Dashboards report what moved, when, for every system, so the question "did last night's changes reach the CRM" has an evidence-based answer. When something does go wrong, the platform shows where flow stopped and how much is waiting, which turns diagnosis from guesswork into a short read.

Data movement rests on the mappings you defined and the canonical model they target. For the platform overview, see How STRAX works.