Data synchronisation
Keeping distributed sites in step with a central hub over unreliable links - change capture, authenticated transport, replay protection and an auditable trail.
Plenty of organisations do not have the luxury of one database and a reliable connection to it. Clinics, field offices, branches and enrolment teams work where the link is intermittent or absent, and the data still has to arrive - completely, once, and in a form somebody can verify afterwards.
The synchronisation module keeps distributed sites in step with a central hub. It is the capability behind deployments that collect data across many sites and consolidate it centrally, including registration programmes operating at national scale.
How it behaves
Changes are captured, not re-sent. Each site tracks what has already been transmitted and sends only what has changed since. A site that has been offline for a week sends a week of changes, not its entire database.
Batches are acknowledged. A batch is applied at the hub and confirmed before the site advances its position. An interrupted transfer is retried rather than assumed, and a batch that has already been applied is not applied twice.
Interrupted transfers resume. Losing a connection mid-transfer costs the remainder of that batch, not the run.
Both directions. Reference data, configuration and centrally-managed records flow back out to sites, so a site is not merely a sender.
Transport options
Deployments differ in what their network and security teams will permit, so the module supports more than one route to the hub:
| Route | Typical use |
|---|---|
| Over the web | The default - sites reach the hub over the internet or a VPN |
| Direct database connection | Sites already on a trusted private network |
| File transfer over SSH | Restricted environments where only a file-based channel is permitted |
The choice is configuration. A deployment can run different sites on different routes where the estate demands it.
Security
Every request is authenticated, and the hub verifies it in a way that does not leak information through timing. Requests carry a freshness window and a single-use value, so a captured request cannot be replayed later. Transport encryption, certificate verification and host-key pinning are supported on the routes where they apply.
Two deliberate design decisions worth knowing during an evaluation:
Hardening is staged, not flipped. Stronger authentication is emitted alongside the established mechanism so a fleet running mixed versions keeps working during a rollout. Only once every site has been upgraded does the hub start refusing the weaker one. This is what makes it possible to harden a live estate of many sites without an outage.
New behaviour defaults to dry-run. Steps that touch live data report what they would apply before they are permitted to apply anything. You see the effect of a change before it is real.
Verification and audit
Synchronisation that cannot be audited is not finished. Every deployment gets:
- a per-site record of what was sent, what was received and what was applied
- position markers showing exactly how far each site has progressed
- a registry of which data is in scope for synchronisation
- comparison between site and hub, so drift is detected rather than discovered
That last one matters. The question after any sync run is not “did it run” but “is the hub now the same as the site”, and it should be answerable without a manual export.
Sensible limits
- Consistency is eventual. A site that has been offline is behind until it reconnects. Systems that need a single authoritative real-time view should run against the hub directly.
- Conflict handling is a configuration decision, made per dataset. Where two sites can edit the same record, the rule for resolving that is agreed during implementation rather than assumed.
- The link’s capacity is still the link’s capacity. Sync makes intermittent connectivity workable; it does not make a saturated connection fast.
Where it fits
Sites are usually running the same modules as the hub - financial records, registrations, case files - with synchronisation underneath. Other systems generally consume the consolidated view at the hub via REST or GraphQL rather than integrating with individual sites.