How would you integrate SaaS with a batch-only legacy ERP?

Question

IT Interview Practice · Accepted Answer

Design an **asynchronous, recoverable exchange** that respects the ERP’s batch limits. First agree on acceptable business delay and which system owns each data entity; do not promise real-time completion on top of an hourly import.

## Architecture and ownership

```text
[SaaS API/events] --> [Durable staging] --> [Mapping adapter]
                                               |
                                         [Batch files]
                                               |
                                         [ERP importer]
                                               |
[Status + reconciliation] <------------- [Result files]
```

For an illustrative sales integration, SaaS owns the submitted order request and ERP owns the posted financial document. Map their identifiers explicitly. An adapter translates statuses, units and field meanings so ERP-specific conventions do not spread into the SaaS-facing workflow.

## Make each step recoverable

Persist incoming work before acknowledging it where the source protocol allows. If polling is required, use a durable checkpoint and overlap or replay rules that avoid losing boundary records. Keep batch identifiers, record identifiers, schema versions, counts and checksums. Publish complete files atomically where supported, or use a separate completion marker.

Track each record through pending, submitted, accepted or rejected states. A successful file transfer does not mean a business record was posted. Parse ERP results and reconcile business identifiers and amounts, not just file counts. Quarantine invalid records with reasons and an accountable operator.

## Handle the ambiguous failure

If the ERP posts a batch but its acknowledgment is lost, blindly resending can duplicate business documents. Use the ERP’s supported duplicate key or query/reconciliation capability before retrying. If neither exists, stop ambiguous records for controlled reconciliation; an adapter-side ledger alone cannot guarantee exactly-once effects in the ERP.

## Capacity and operations

Estimate whether one import window can drain the backlog, including peak volume and recovery after an outage. Apply backpressure and show users a pending state with realistic timing. Alert on oldest pending age, rejection rate and reconciliation mismatches. Protect staged files and define access and retention responsibilities.

## Interview signal

Explain the consistency boundary and recovery process. “Add a queue” does not solve semantic mapping, partial acceptance or an ERP that cannot deduplicate retries. The design trades immediacy for compatibility and must make that delay visible to the business.

Reference: [Microsoft: anti-corruption layer](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer).

Architecture and ownership

Make each step recoverable

Handle the ambiguous failure

Capacity and operations

Interview signal

Related questions