Suggested answer

1. Start from the business process rather than the systems. Which business event triggers the exchange, and what business outcome depends on it.
2. Define the data contract precisely: which fields, in which direction, with what data types, what the system of record is for each field, and how conflicts are resolved when both sides change a value.
3. Establish timing and volume requirements — real time, near real time, or batch — along with expected message volumes and peak rates, since these drive the integration pattern and interact with platform limits.
4. Specify error handling as a business requirement, not just a technical one: who is notified when a message fails, what the business does in the meantime, and whether retries could create duplicates.
5. Agree ownership on both sides. Integration requirements typically involve a third party with their own release cycle, so I would document the dependency with a named owner and a target date, and treat any change to their schedule as a risk to ours.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.