1 min lesson
Choosing the integration style per hop
Compare two rows from "Choosing the integration style per hop", then say when each one fits.
Step 1 of 2
Choosing the integration style per hopwebhooks vs batch vs CDC
There is no single right transport. You pick per system based on latency needs, volume and what the source can emit.
- Style
- Webhooks / events
- Best for
- Low-latency reactions (payment succeeded, invoice finalized)
- The trade-off
- Must handle retries, dedup and missed deliveries; pair with a reconciliation sweep.
- Style
- Batch / scheduled
- Best for
- Bulk posting to the ERP, period rollups, GL journals
- The trade-off
- Simple and auditable, but stale between runs; fine when the SLA is hours.
- Style
- CDC (change data capture)
- Best for
- Streaming row-level changes from a source DB
- The trade-off
- Near-real-time and complete, but couples you to the source schema.
| Style | Best for | The trade-off |
|---|---|---|
| Webhooks / events | Low-latency reactions (payment succeeded, invoice finalized) | Must handle retries, dedup and missed deliveries; pair with a reconciliation sweep. |
| Batch / scheduled | Bulk posting to the ERP, period rollups, GL journals | Simple and auditable, but stale between runs; fine when the SLA is hours. |
| CDC (change data capture) | Streaming row-level changes from a source DB | Near-real-time and complete, but couples you to the source schema. |
A common pattern: webhooks for fast signals, a nightly batch for GL posting and reconciliation to catch whatever the webhooks missed.
Interview move
When you propose a webhook integration, immediately add the reconciliation sweep that backstops it. Saying "webhooks for latency, reconciliation for correctness" in one breath signals you have actually operated a financial integration in production and know webhooks alone are never enough.