Build an interface catalog as a maintained inventory of system-to-system contracts and their owners. It connects an architecture diagram to the details teams need for implementation, incident response and change planning.
Walk through a real process, such as order fulfillment, and list every API call, event, file transfer and scheduled data exchange. Include less visible paths such as reconciliation exports and manual recovery imports.
For each interface, record:
Interface IF-07 sends shipment confirmations from a warehouse to an order platform every 15 minutes. The warehouse owns the feed; the order platform owns ingestion. The contract defines a shipment identifier, schema version, record count and acknowledgment file. Missing acknowledgments are escalated to a named support team.
This is more useful than an arrow labeled “integration”: it lets a team identify whether a delayed shipment update is a transport failure, rejected data or a missed schedule.
Link to schemas and runbooks instead of duplicating their contents. Update the catalog when an interface changes, and periodically compare it with observed traffic and scheduled jobs. A static inventory quickly misses unofficial connections.
An endpoint list alone does not describe a contract. A strong answer includes business meaning, ownership and failure behavior, while choosing enough detail to remain maintainable.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate