What each one is
In real-time sync, a change in one system is sent to the other as it happens, usually within seconds. This is done with webhooks, event streams or direct API calls. Strictly speaking it is near real time, since there is always some delay.
In scheduled sync, also called batch sync, a job runs at set times, such as every fifteen minutes or once a night. It collects what changed since the last run and transfers it in one go.
The two options at a glance
| Real-time sync | Scheduled sync | |
|---|---|---|
| Freshness | Seconds | As old as the interval between runs |
| How it is triggered | By each change, as it happens | By the clock |
| When the other system is down | Events must be queued and retried, or they are lost | The next run picks up where the last one stopped |
| Load on the systems | Constant, in small pieces | In bursts, which can be timed for quiet hours |
| Order of events | Must be handled, since events can arrive out of order | Usually simpler, since a run sees the final state |
| Finding a problem | Harder. One event among thousands went wrong | Easier. One run failed, and can be rerun |
| Cost to build and operate | Higher | Lower |
Ask how fresh the data needs to be
The useful question is not whether real time would be nice. It is what goes wrong if the data is ten minutes old, an hour old or a day old. Put that question to each flow.
| Data | Who acts on it, and when | Usual answer |
|---|---|---|
| Stock available to sell | A customer, at checkout | Real time, or the item is sold twice |
| Payment status | The customer and the order system, at once | Real time |
| A new support ticket | An agent, within minutes | Real time, or every few minutes |
| A new lead from a form | A salesperson, within the hour | Either. A short interval is usually enough |
| Product descriptions and prices | Customers, over days | Scheduled, unless prices change during the day |
| Orders to accounting | A bookkeeper, at the end of the day or month | Scheduled |
| Data for reports | Managers, the next morning | Scheduled, nightly |
When each one fits
Choose real time when
- A person or a system acts on the data within seconds or minutes
- Stale data causes a visible error, such as overselling or double booking
- The user is waiting for a confirmation on screen
- Both systems offer webhooks or events
- You can operate queues, retries and monitoring
Choose scheduled when
- The data is used hours or days later
- Volumes are large and can be moved in bulk at quiet times
- One system only offers file export or a slow API
- Simplicity and easy recovery matter more than speed
- A run can be reconciled against totals
There is a useful middle. A scheduled job that runs every few minutes gives data that is fresh enough for many purposes, with most of the simplicity of batch.
What real time needs in order to be reliable
Real-time sync is easy to demonstrate and hard to make dependable. These are the parts that separate the two.
- A queue. Events are stored until they are processed, so that an outage on one side does not lose them
- Retries with limits. Failed events are tried again, and set aside for a person after repeated failure
- Protection against duplicates. The same event may arrive twice, and processing it twice must do no harm
- Ordering. An update can arrive before the record it updates, and the integration must cope
- Monitoring. Someone is alerted when events pile up or fail
- A reconciliation job. A scheduled comparison of both systems that catches whatever the events missed
The last item is worth noting. Dependable real-time integrations nearly always include a scheduled check as well. The two approaches are partners more often than alternatives.
A worked example
A furniture retailer with a store, a warehouse and accounting
The retailer is invented. Its first request was to make everything real time.
- Stock levelsShown to customers and reserved at checkout. An hour's delay would mean selling items that are gone. Decision, real time, with a nightly reconciliation.
- Order statusCustomers check it a few times a day. Decision, scheduled, every ten minutes.
- Product catalogUpdated by the buying team weekly. Decision, scheduled, nightly.
- Invoices to accountingReviewed at the end of each day. Decision, scheduled, once in the evening, reconciled against the day's order total.
One flow of four needed real time. Building all four that way would have multiplied the cost and the points of failure for no benefit anyone would notice.
A checklist for each data flow
Real time or scheduled
0 of 7 checkedWhat to do next
List your data flows and write beside each how old the data may be. That column decides most of the design. Our comparison of custom integrations and existing connectors covers the other half of the decision.
Our API development and backend systems pages explain how we build integrations that have to be dependable. You can also send us your list of flows, and we will mark which we would make real time.
Common questions
Is real-time sync always better?
No. It is better only where someone acts on the data quickly. Elsewhere it adds cost, moving parts and ways to fail, with no benefit a user would notice. Scheduled sync is simpler to build, easier to recover and easier to check, which makes it the better default.
How often should a scheduled sync run?
As often as the freshness you need, and no more. Nightly suits reporting and accounting. Every few minutes suits operational data that people check during the day. Very short intervals on large datasets can strain the source system, so match the interval to how the data is used.
What are webhooks?
A webhook is a message one system sends to another when something happens, such as a new order. It is the most common way to do real-time sync between web applications. Webhooks can be delayed, repeated or occasionally missed, which is why reliable integrations add queues, duplicate protection and a periodic reconciliation.
Can we change from scheduled to real time later?
Yes. Starting with a scheduled sync is a sound way to get systems working together and to learn where freshness matters. Individual flows can then be moved to events. The scheduled job often stays in place as the reconciliation that keeps the real-time flow honest.