Order Status in Three Seconds on a Batch-Bound ERP
Northwind Components runs a 14-year-old on-premise ERP that holds all order, pricing, and inventory data. The ERP exposes only a nightly batch extract; the batch window is 22:00-04:00 and any slippage delays the plant's pick lists. A newly purchased SaaS CRM must show order status and available-to-promise within 3 seconds of a sales rep opening an account, and must create quotes that become orders in the ERP. There are 40 existing point-to-point interfaces, mostly file drops, brokered by an enterprise service bus whose vendor stops supporting it in 11 months. The integration team has four engineers. The CIO has mandated that no new interface may bypass the API gateway. Finance requires that no quote be lost and no order be created twice.
1. Recommend an integration pattern for the order-status read path and for the quote-to-order write path, and justify why the two should not use the same pattern.
Read the worked answer
The two paths have different failure economics, so treat them differently.
Read path - asynchronous, event-driven. Publish order and ATP changes from the ERP (outbox table → change stream → gateway) into a CRM-facing cache. The 3-second target is a freshness requirement, not a synchronous-call requirement; the ERP cannot absorb per-page-load queries from every sales rep. Hold the cache to a documented staleness bound (for example 30 seconds) and display a last-updated timestamp so reps can judge what they are seeing.
Write path - synchronous API with idempotency. A quote-to-order call must return a definitive accept or reject, so expose a request/response API on the gateway carrying a client-generated idempotency key. On the ERP side write to an inbox table first, then apply, so a retried call cannot create a second order.
Why not one pattern: reads are high-volume, tolerate seconds of staleness, and must never block the ERP. Writes are low-volume, tolerate no loss or duplication, and need an authoritative acknowledgement. Making everything asynchronous loses that acknowledgement; making everything synchronous overloads the ERP and still violates the gateway mandate.
2. The CRM vendor asks for a read-only database login directly to ERP tables, arguing it is simpler than building an API. Evaluate the request.
Read the worked answer
Decline, but decline with an alternative rather than a refusal.
Technical objections. A direct login couples the CRM to the ERP's physical schema, so any ERP patch, index change, or column rename becomes a CRM outage nobody is tracking. Read-only is not harmless: long-running queries from an external SaaS tenant share the ERP's connection pool and can starve the batch window that produces the plant's pick lists. It also bypasses the API gateway, which the CIO has prohibited outright, and bypasses whatever throttling and audit the gateway provides.
Control objections. A vendor-held credential to production financial data is a standing access grant that is hard to scope, hard to revoke, and hard to evidence at audit. It also exports ERP data into a third party without a data-processing agreement covering that flow.
Alternative to offer. A gateway-published, contract-versioned read API backed by a replica or the change-stream cache, with per-client rate limits, scoped to only the fields the CRM needs. If the vendor's real problem is bulk initial load, offer a one-off governed extract instead of a permanent login. Ask what report they cannot build on the API - the answer often reveals a single missing field, not a need for schema access.
3. Sequence the decommissioning of the 40 ESB interfaces within the 11-month support window using four engineers. State what you would stop doing.
Read the worked answer
Treat it as a portfolio triage, not a queue, and be explicit about what will not fit.
1. Inventory and classify (weeks 1-3). For each of the 40 interfaces record: volume, criticality, owning application, whether the ESB is doing real mediation (transformation, routing, protocol bridging) or merely moving a file, and the target pattern. Most file-drop interfaces are cheap; a handful will carry most of the risk.
2. Estimate honestly. With four engineers and roughly 40 weeks of usable capacity, you cannot do 40 bespoke rebuilds. Budget something like 1 engineer-week for a simple file move and 3-5 for a mediated transformation. That arithmetic will show the plan does not close - surface it in week 3, not month 10.
3. Retire before you rebuild. Retire interfaces with no live consumer, and consolidate near-duplicate feeds. Kill two interfaces and you have bought a week.
4. Migrate in risk tiers. Batch/file first, then low-volume synchronous, then the order-critical flows, each with a parallel-run period and a cutover rollback.
5. Stop doing: new point-to-point builds, non-critical enhancements on ESB-hosted flows, and any interface with no named business owner.