Real-time vs batch synchronization

A decision framework for when commerce data should move instantly, on schedule, or through event queues.

Book discovery · Read integration services

In this guide

• Decision dimensions
• Pattern selection matrix
• Replay and ordering risks
• Build and testing checklist
• Monitoring and operating model
• FAQs

Why this matters

“Make it real time” is often an expensive way to avoid deciding what the business actually needs. Some commerce flows must be synchronous because the customer is waiting. Some should be event-driven because resilience and replay matter. Some should be scheduled because the data is operational rather than transactional. Some should remain batch because reconciliation is more important than immediacy.

The decision should be made per business object and failure mode, not per platform. Inventory availability, catalog enrichment, order export, payment settlement, product media, price lists, and analytics events do not deserve the same synchronization pattern.

Decision dimensions

Score each flow against these dimensions before choosing a pattern:

• Customer visibility: does stale data block checkout, create wrong promises, or only affect back-office reporting?
• Allowed staleness: seconds, minutes, hours, daily, or finance-close.
• Ordering sensitivity: can messages arrive out of order without corrupting state?
• Replayability: can the event or file be safely replayed with the same idempotency key?
• Volume and cost: will real-time fanout create operational cost or rate-limit pressure?
• Blast radius: does failure affect one customer, one catalog segment, one market, or the whole order flow?
• Owner response time: can the owning team respond quickly enough for a real-time failure?

Pattern selection matrix

• Synchronous API: use for checkout-blocking decisions where the caller must show immediate success or rejection.
• Event or queue: use for order export, stock updates, status changes, and flows that need durable replay.
• Scheduled job: use for enrichment, price refresh, catalog health checks, or operational sync where lag is acceptable.
• Batch/file: use for finance, supplier, warehouse, or legacy flows where reconciliation, audit, and restart evidence matter more than seconds.

Replay and ordering risks

Real time is not automatically safer. If the flow cannot tolerate duplicates, out-of-order updates, late acknowledgements, or partial downstream failure, a queue with replay controls may be safer than a direct API. If the flow needs a signed settlement report, batch may be more reliable than streaming individual events that finance later has to reconstruct.

sync_decision:
  flow: "inventory availability to storefront"
  customer_visibility: "high"
  allowed_staleness: "minutes"
  ordering_sensitive: true
  replayable: true
  recommended_pattern: "event-driven with reconciliation snapshot"
  fallback_pattern: "scheduled snapshot when event lag exceeds threshold"
  owner_response_time: "business-hours operations plus on-call during peak"

What to test before launch

Test each selected pattern under delay, duplicate delivery, missing acknowledgement, partial downstream outage, and replay. A real-time path needs timeout and fallback behavior. An event-driven path needs dead-letter handling and idempotency. A scheduled path needs stale-data alerts. A batch path needs restart evidence and reconciliation totals.

Operate with synchronization reviews

Review patterns after launch using evidence: lag, duplicate count, replay count, stale records, unresolved conflicts, and manual interventions. If the team cannot explain why a flow is real time, scheduled, or batch, the decision is probably inherited rather than designed.

Examples by commerce object

Stock availability often works best as event-driven updates plus a scheduled reconciliation snapshot, because checkout needs freshness but operations still need proof when an event is missed. Product enrichment can usually tolerate scheduled movement because buyers do not need every descriptive attribute in seconds. Order export deserves durable queues because ERP acknowledgements, duplicate detection, and replay evidence matter more than a synchronous response. Payment settlement should be reconciled against gateway or acquirer reports rather than treated as a stream of isolated events. Search indexing may need incremental updates during the day and a full rebuild at controlled windows.

These examples are not rules for every estate. They show the reasoning style: decide based on customer promise, allowed lag, audit requirement, and recovery cost. If a team cannot state those factors, the pattern is probably an inherited vendor default.

Synchronization decision checklist

• Decide allowed staleness in business language.
• Test duplicate, delayed, missing, and out-of-order messages.
• Require idempotency for every replayable flow.
• Keep reconciliation snapshots for event-driven state.
• Alert on lag by business object, not only by queue depth.
• Revisit real-time choices after peak traffic and finance close.

FAQs

Should customer-visible data always be real time?

Not always. Customer-visible data often needs freshness, but the safest pattern may be an event-driven flow with a reliable fallback snapshot rather than a synchronous dependency that can block checkout.

When is batch the better choice?

Batch is often better for settlement, finance posting, supplier feeds, warehouse reports, and legacy integrations where auditability and restart evidence matter more than low latency.

What is the main warning sign of the wrong pattern?

The main warning sign is manual reconciliation after every failure. If every incident requires hand-building state across systems, the synchronization pattern lacks evidence, replay control, or ownership.

Related pages

• Integration services
• Architecture review
• ERP integrations
• Middleware and iPaaS

Review synchronization decisions before they become support debt.

CCI can map which commerce flows need synchronous APIs, durable events, scheduled jobs, or audited batch processes based on customer promise and recovery evidence.

Book discovery · See how we work