The system of record updates nightly and cannot be changed. Product teams need to build against it. Design the integration.

What is being tested

Whether you make the staleness explicit rather than hiding it, and whether you shield the legacy system from a load it was never sized for.

The architecture

One integration service owns the legacy relationship. Nothing else speaks to the legacy system, holds a connection, or knows its format. This is an anti-corruption layer, and enforcing it with a build-time check is what makes the legacy system replaceable later — otherwise "replace the mainframe" eventually means touching every service.

Reads are served from a projection, not from the legacy system. Changes are captured — via change data capture, a batch extract, or a message feed — into a store shaped for the modern access pattern. This is the load-bearing decision: it decouples read performance and availability from a system you do not control and cannot scale.

Writes are queued and applied on the legacy system's terms, with the modern system tracking the pending state so the user is shown something honest while the write is in flight.

Making staleness explicit

The most important interface decision: do not pretend the data is current. Every response carries an as_of timestamp. Product teams then build correct experiences — "stock as of 06:00" — rather than discovering the batch boundary through a customer complaint.

Hiding staleness behind a normal-looking API means every consumer independently assumes real-time and every consumer is independently wrong.

Protecting the legacy system

The system was sized for a fixed internal load. A new consumer generating ten times the query volume can degrade the system of record for the entire business, which makes rate limiting on your side a protection for them:

• Cache aggressively — staleness is already accepted, so caching costs nothing extra.
• Batch requests rather than issuing them individually.
• Rate limit and queue, with a defined behaviour when the limit is reached.
• Respect the batch window: know when the system is unavailable and fail fast with a meaningful error rather than hanging.

Translating the failure model

Batch windows, locked files, session limits and truncated fields must become domain-meaningful errors. SYSTEM_UNAVAILABLE_UNTIL_0600 is actionable; a raw connection error from a 1990s protocol is not.

Handling the write path honestly

A write that will be applied in tonight's batch is not a completed write. The API should return a pending state with an identifier, the modern system should track it, and the user interface should show it as pending. Reconciliation confirms it after the batch, and raises an alert for anything that did not apply.

What a strong answer adds

Naming the reconciliation requirement explicitly. Any asynchronous boundary between two systems that both matter will diverge — from a lost message, a rejected record, or a manual edit made during an incident. Something must periodically compare the two and report differences. This is permanent work, not a migration task, and it is the mechanism that catches every bug you have not thought of.