What your customer's IT team will ask before your service goes on their network
Before a sync service runs inside a warehouse or plant, the IT team will ask what connects where, what is encrypted, and what runs on which machine. Here are honest answers.
Your product already runs at your customer sites, beside its own database. Now you want a copy of that data in your cloud application, which means one more piece of software inside a network you do not own. The people who guard that network will have questions, and the deal often moves at the speed of their answers.
The questions are predictable, and good answers are short, specific and honest about the limits.
Which way does the traffic flow
This is nearly always the first question. The IT team wants to know whether anything outside their network can start a conversation with anything inside it.
For the design we run, the answer is no. A small service sits inside the site network and makes outbound connections only. No port is opened to the internet, and nothing reaches in. The data flow is one way: out of the site, into a central store. Nothing is written back to the site database.
That last point matters. The service does not change rows at the site, push commands or offer remote control; none of that is part of what it does. Once the IT team hears "outbound only, nothing written back", the firewall conversation tends to get much shorter.
What runs on which machine
The next question is footprint: what they are hosting, where it lives and what it can touch. There are three places.
At the site
A small service runs on a server, a virtual machine or a PC inside the site network. It needs access to the site database and outbound internet access, and nothing more. It reads changes, queues them on the local disk and sends them out.
On the wire
Changes travel in batches every few tens of seconds. Each batch is compressed and encrypted with a key unique to that site, then sent over an outbound connection.
In the cloud
A receiver writes each site into low-cost document storage, a database that holds flexible documents rather than fixed tables. Every row is stamped with its site and arrival time, and each site keeps its own space. Your application reads from there, not from the site.
How hard it leans on the site database
Operations people worry about anything that competes with the system the warehouse runs on. A sync job that slows picking during a peak gets switched off, and rightly so.
After a first full copy, sent once and table by table, the service reads only the rows and columns that changed since its last look. On SQL Server it uses change tracking, a built-in feature that notes which rows changed, and reads it on a short interval. On MongoDB it uses change streams, and on PostgreSQL it uses logical replication; both are the database's own built-in feeds of changes, and both are streamed. Dynamic throttling eases off when the site is busy, so operational database performance comes first.
Your team chooses and ranks the tables, and can set filters to prioritize rows.
How the data is protected
Reviewers will ask what is encrypted, and with which keys.
Every site has its own key. Changes are encrypted with the key for that site before they leave, so no single key is shared across every site. Centrally, each site sits in its own space, with every row stamped by origin.
If you cannot answer a security question from what the product does, say so and find out, rather than guess.
Reviewers remember a confident wrong answer far longer than an honest "we will confirm that in writing".
What happens on a bad day
The IT team will ask what happens when the link drops or the server restarts.
- If the link drops, changes keep queueing on the site disk and go out when it is back.
- If something restarts, each table resumes from the last change it sent.
- If a site is cut off for days, it resumes from where it left off. Nothing is lost.
- Queued changes are removed only once the cloud confirms receipt.
- If a site goes silent, it reports its health, so a stalled site is noticed rather than discovered later.
Delivery is at-least-once: a change may occasionally arrive twice, but is never dropped. Reviewers trust a precise claim more than a perfect one.
What it is not
A clear list of boundaries ends many arguments early:
- It is one way. Nothing is written back to the site.
- It carries database tables only, not files, video, device streams or remote control.
- The central copy is current within a couple of minutes, not instantly.
- It is not a local read copy. Site applications keep reading their own database.
- Each site needs its own setup, and a person drives the rollout.
The central copy also takes reporting load off the site. Reports run against it, so the onsite database keeps headroom to stay resilient during peaks. That is a claim about resilience, not about making anything faster.
Who runs what
The last question is ownership. In our model, redfly installs and operates the site service, watches its health and handles backfill and recovery. The cloud account is yours by preference, or fully managed by redfly, or onsite, with no proprietary cloud services. Your team chooses and ranks the tables, owns the application and its reports, and provides one contact per site.
redfly is the sync layer in that picture: a small outbound service at each site and a central store your application reads. We keep the data flowing; you build what your customers see.