Replication vs Scheduled Transfer for Keeping Many Sites in Sync

Two very different machines both promise to "keep the branches in sync." One is replication: a continuous engine that watches a folder tree and quietly makes remote copies converge on it. That includes the share replication built into server operating systems and storage appliances, and the various folder sync engines. It includes anything else that runs all the time and chases change. The other is the scheduled transfer job: an explicit task that runs at a chosen time, moves named files to named destinations, and reports an outcome. At one site the choice between them is a preference. At forty sites it is an architecture decision. Everything the two machines do differently — consistency, conflicts, bandwidth, failure behavior — gets multiplied by the fleet.

This article compares them specifically for the one-to-many case. That means many sites, thin links at some, and deadlines at stake. It means a business that will eventually ask you to prove which sites are current. By the end you will know which machine fits which flow, and why the honest answer for most estates is both — in different places. You will know how to make the choice per flow with a short list of questions. This article is part of our Multi-Site Distribution series.

Two Machines, Briefly Recapped

The one-to-one comparison — what replication fundamentally is, what a transfer job fundamentally is, and how each behaves between a single pair of servers — has its own foundation article: replication vs transfer jobs. If the two concepts are new, read that first; this article multiplies its conclusions by forty.

The short recap. Replication is state-based: you declare that tree B at the branch should mirror tree A at the center. The engine continuously works to make that true, transferring whatever changed, whenever it changed. There is no "run" — there is an ongoing relationship. A scheduled transfer job is event-based: at half past one, connect, transfer these files, verify, log, and finish. It has a start, an end, and a result. Everything that follows flows from that single difference: one machine maintains a condition, the other performs an action.

The boundary is behavioral, not brand-based. A folder-comparison tool run once nightly by a scheduler is a job, whatever its box says. The same tool looping every minute has become replication in every way that matters here. Classify what you have by when it moves data and whether a run has a result, and the rest of this comparison applies cleanly.

Consistency: Convergence vs a Fleet Moment

Replication promises eventual convergence: each site drifts toward the source and, given quiet time, arrives. The word doing the quiet damage is eventual. Each of forty sites converges on its own schedule, governed by its own link and its own backlog. So at any given instant the fleet is a smear — some sites current, some seconds behind, the thin-link ones perhaps hours behind. For a shared working folder, nobody cares. For a price file that must be in force everywhere on opening day, the smear is the problem.

Scheduled transfer gives you release semantics instead. A job delivers a named version — prices_YYYYMMDD.csv, release folder and all — inside a window you chose. When the window closes you can say a sentence replication can never quite say: "all forty sites received release such-and-such before seven." That sentence is a fleet moment: a point in time at which the estate provably matched. The identicality axis from the problem-shapes article tells you which flows need one. Flows that merely need convergence tolerate replication. Flows with a deadline or a coordinated cutover essentially demand release semantics. Or they force you to rebuild release semantics awkwardly on top of a replication engine — version markers, settle checks, and prayer.

There is a second consistency trap that only shows itself with multi-file releases. Replication moves files, not releases. When the center saves twelve files into the published folder, the engine propagates them one by one, in its own order. For a while each branch holds an arbitrary mixture of old and new. Site software that reads the folder mid-propagation sees a set that never existed at the source. Job-based distribution avoids this by construction when paired with the standard publish discipline. Assemble the release out of sight, then make it visible in one atomic step. Let the job deliver a version that is complete by definition. Replication can be taught the same manners (publish into a fresh folder, flip a marker), but you must remember to teach it. The engine will happily propagate your half-assembled state, because half-assembled state is still state.

Note what neither machine gives you for free: proof. Replication does not report per-site currency. Most engines will tell you their backlog if asked, but "the engine is idle" is not evidence anyone can audit later. A transfer job at least produces a per-run, per-site log line as a natural byproduct. Either way, fleet-level verification is its own layer — built in proving every site got the right version. But jobs hand that layer its raw material, while replication makes it dig.

Conflict Honesty

Here is the section that saves the most pain, and it turns on one question: can a branch change the files?

Distribution is one-to-many. Content flows outward; branches consume it. In a healthy distribution flow there is no such thing as a conflict, because only one side ever writes. But replication engines are frequently configured two-way — it is a checkbox, it feels generous, and at one or two sites it may even work. At forty sites, two-way replication of distributed content is a slow catastrophe. When a branch manager "fixes" a price locally at the same time the center publishes a new file, the engine must pick a winner. One common policy is last-writer-wins. Someone's change is silently destroyed, possibly the center's, propagating one branch's improvisation to the whole fleet. The other common policy is conflict copies. These quietly seed every replica with prices (conflict copy from branch-011).csv until the tree is a museum of disagreements. Neither is malfunction; both are the engine doing exactly what two-way convergence means. The dishonesty is in pretending a fleet has no simultaneous writers.

The honest design rules are short:

• Distributed content is read-only at every site. Enforce it with permissions, not policy memos. A branch that needs a local exception has found a gap in your process — fix the process centrally.
• Data that branches produce is a different flow. Sales files, logs, local reports — that is collection, the mirror image of distribution. Give it its own folders and its own jobs flowing inward. Never let one two-way tree carry both directions "for convenience."
• Prefer machinery that makes direction explicit. A transfer job states its direction in its definition — this file, from here, to there. That small bureaucracy is a guardrail: nobody accidentally builds a fleet-wide merge because a checkbox defaulted to two-way.

Bandwidth: Trickle vs Burst

The two machines also spend the network completely differently. At multi-site scale the difference lands on the two most contested resources you own: the branch link and the hub's uplink.

Replication trickles. It follows churn — every save at the center becomes traffic to forty sites, all day, during business hours, because that is when people change files. On well-provisioned links this continuous drip is a virtue: no burst, no window to plan, changes arrive minutes after they happen. On a thin branch link shared with the tills and the card terminals, the same drip becomes a rival to the business itself. Some engines offer schedules or throttles. But the control is coarse compared with what a scheduled job gives you for free: silence except when you asked for traffic.

Jobs burst. A nightly job moves everything in one deliberate window. You place it in the quiet hours, size it against the link, and stagger it across the fleet in waves. That way, the hub's uplink is never oversubscribed. The cost is that the burst must fit the window. A release too big for the night needs deltas, compression, resume, and the other thin-link tactics covered in distributing over thin and unreliable links. The delta techniques themselves — sending only changed portions rather than whole files — are the same ones described in rsync mirroring patterns. Good replication engines use similar tricks internally. The difference is not cleverness but when the traffic happens and who decided.

One multi-site subtlety deserves emphasis: the hub multiplies whatever profile you choose. Forty trickles are a permanent background load on the hub's uplink, proportional to daytime churn you do not control. Forty bursts are a planned nightly load you shape explicitly. Estates with heavy daytime churn and thin links generally find the burst model the only one they can actually reason about.

Failure: Silent Divergence vs a Red Row

How each machine fails may matter more than how it succeeds.

When replication to a site breaks — credentials expired, disk full, service stopped by a well-meaning restart — nothing runs and fails. The engine simply stops converging that replica, and the site begins to drift, silently, while every mechanism you would normally watch stays green. Discovery typically happens when a human notices stale content at the branch, which is to say: weeks later, from a complaint. Guarding against it means monitoring backlog and per-replica health, which mature engines expose but few teams actually wire into alerts.

When a transfer job to a site fails, there is an event: a run, an error, a log line with a timestamp. Retry logic can act on that event, and a notification can announce it. The failure is a red row in a place you already look. Better, the job's history doubles as delivery evidence — site, file, time, outcome — the raw material of the distribution report. And absence is catchable too. A job that never ran leaves a gap that a freshness check can detect the same night. That uses the expected-files techniques in freshness checks and expected files.

This is not a claim that job estates never fail silently — a disabled schedule is exactly as quiet as a broken replica. The claim is about repair surface. A job failure is an event you can alert on with tooling you already have. Replication failure is a condition you must go looking for.

The Decision Table

Here is the comparison assembled, with the multi-site consequences spelled out.

Where Each Belongs in One Estate

Framed this way, the machines stop competing, because most estates contain both kinds of problem. The realistic mapping looks like this:

• Replication earns its keep between well-connected peers with convergence-tolerant content. Two file servers in the head-office campus keeping a departmental share aligned; a pair of hub servers mirroring each other for resilience. Fat links, no fleet deadline, content where "a minute behind" is meaningless — this is what continuous convergence was built for.
• Scheduled transfer owns the hub-to-branch leg. Releases with names, windows with deadlines, links with limits, and a business that asks for proof: every force in the one-to-many problem pushes toward explicit jobs. The nightly price file, the weekly content set, the per-branch data feeds — jobs, all of them.
• The boundary between the two is the hub's release area. Internal systems may replicate content into the hub however they like. The moment content crosses into the published release area, it moves onward by job, with a version, a window, and a log line per site.

It is worth saying that the job side has absorbed the best habit of the sync world. A mirror task — "make the branch's folder match this release folder, transferring only what differs" — gives you sync's convenience with a job's semantics. It runs on a schedule, in a window, with retries, notifications, and a logged outcome. In Sysax FTP Automation such mirror and sync tasks are wizard-generated rather than scripted, so the per-branch job is a few minutes' configuration. Pointed at a hub running Sysax Multi Server, each branch's mirror run also lands in the hub's activity log. That is exactly the per-site delivery evidence the verification layer wants. Directed sync on a schedule, in other words, is not a compromise between the two machines — for distribution it is the correct synthesis.

Choosing per Flow: Five Questions

When a specific flow is on the table, these five questions settle the machinery quickly. Ask them in order and write the answers into the flow's census sheet.

1. Can every site's copy be read-only? If no — if sites must edit the same files that arrive — stop and split the flow into an outbound distribution and an inbound collection before choosing anything.
2. Is there a deadline or cutover moment? A fleet moment means release semantics, which means jobs (or heavy scaffolding on top of replication that you will regret).
3. What is the thinnest link, and is it shared with the business by day? Daytime-shared thin links argue for bursts in off-hours windows — jobs again.
4. How often are sites offline, and who should absorb that? Frequent absence favors either replication's automatic catch-up or a pull-based job design where the returning site fetches the current release itself. That pull-based design is the offline-branch pattern covered in this series' hub-designs article.
5. What proof will someone eventually demand? If the answer involves "show me every site got it," jobs produce the evidence as exhaust; replication makes evidence a project.

Score honestly and most branch-facing flows land on scheduled transfer, most intra-campus convenience mirroring lands on replication, and nothing lands on two-way anything.

The Short Version

Replication maintains a condition; a job performs an action. Conditions converge eventually, per site, in silence — actions complete in windows, per release, with receipts. At fleet scale, distribution wants the second. That means explicit direction (which retires the conflict question), bursts you can place on thin links, failures that arrive as events, and logs that become proof. Keep replication for the well-linked internal legs where convergence is genuinely the requirement. From here, thin and unreliable links shows how to make the burst model survive the worst connections in your estate. Our article on proving every site got the right version builds the evidence layer that job-based distribution makes cheap. Both approaches come together in the worked forty-branch design.

Frequently Asked Questions