Integrations fail most often not because of code, but because the wrong pattern was chosen for the job. Each data flow deserves its own decision.
Ask three questions first
- How fresh does the data need to be? Seconds, minutes or overnight?
- Which system is the source of truth? Every shared field needs one owner.
- What should happen when something fails? Retry, alert, queue or stop?
Common patterns
Request and reply (real-time API). One system calls another and waits for an answer — useful when a user needs a result immediately, such as a credit check during data entry. Keep these fast and handle timeouts gracefully.
Fire and forget (events). A system publishes an event, and subscribers react in their own time. Platform Events and webhooks fit here. Good for notifications and loosely coupled systems.
Batch synchronization. Data is moved on a schedule. Ideal for large volumes where minutes or hours of delay are acceptable, such as nightly product or pricing updates.
Middleware. A dedicated layer handles routing, transformation and monitoring across many systems. It earns its place as the number of systems and flows grows.
Design for operations
Whatever the pattern, plan for:
- Clear field mappings and transformation rules, documented
- External IDs so records can be matched reliably
- Logging with enough context to diagnose issues
- Alerts that reach someone who can act
- Safe retries that will not create duplicates
The best integration is the one your team can understand, monitor and change a year from now.
This article is a draft for review.