Integration Design
How an analyst designs system-to-system integrations — integration topologies and types, sync vs async, orchestration vs choreography, message brokers, and the integration design checklist.
17 questions
JuniorTheoryVery commonWhich kinds of integration between systems do you know?
Which kinds of integration between systems do you know?
By mechanism the main kinds are: APIs (REST, SOAP, gRPC, GraphQL) for request/response; message brokers and queues (Kafka, RabbitMQ, IBM MQ) for asynchronous exchange; an ESB for centralized routing; file exchange on a schedule; and direct database connections.
Common mistakes
- ✗Naming only APIs and forgetting brokers, ESB, files, or DB-connect
- ✗Treating a message broker as synchronous request/response
- ✗Confusing an ESB with a single API gateway
Follow-up questions
- →When is file exchange preferable to an API?
- →Why is a direct DB-connect risky as an integration method?
MiddleTheoryVery commonWhy are message brokers used in integration?
Why are message brokers used in integration?
A message broker decouples producer and consumer: the producer hands a message to the broker and moves on, the consumer reads at its own pace. This gives asynchronous interaction, guaranteed delivery (the broker persists and retries until acknowledged), and smoothing of bottlenecks in long integration chains, since the queue absorbs load spikes. At scale, partitions let a topic be consumed in parallel.
Common mistakes
- ✗Thinking a broker speeds up synchronous calls rather than decoupling
- ✗Forgetting persistence + retries is how delivery is guaranteed
- ✗Not knowing partitions enable parallel consumption
Follow-up questions
- →How does a broker achieve guaranteed delivery?
- →How do partitions help consume a topic in parallel?
MiddleTheoryVery commonHow does synchronous interaction differ from asynchronous, and what are orchestration versus choreography?
How does synchronous interaction differ from asynchronous, and what are orchestration versus choreography?
In synchronous interaction the caller waits for the response, coupled to the callee's availability; in asynchronous it sends a message and continues, decoupled by a queue. Orchestration uses a central coordinator driving each step; choreography has systems react to events.
Common mistakes
- ✗Swapping the definitions of synchronous and asynchronous
- ✗Confusing orchestration (central coordinator) with choreography (event reactions)
- ✗Believing async removes the need for delivery guarantees
Follow-up questions
- →When would you choose orchestration over choreography?
- →What is the downside of a synchronous call when the receiver is unavailable?
JuniorTheoryCommonWhich system integration topologies do you know?
Which system integration topologies do you know?
By connection shape: point-to-point — each pair connects directly, simple at first but the link count explodes as systems grow; star/bus (hub-and-spoke, an ESB) — all systems route through one central hub; and mixed. Integrations are also vertical or horizontal.
Common mistakes
- ✗Swapping point-to-point and hub-and-spoke definitions
- ✗Claiming point-to-point scales without link growth
- ✗Confusing the vertical/horizontal axis with diagram orientation
Follow-up questions
- →Why does the number of links in point-to-point grow faster than in a star?
- →What role does an ESB play in the "bus" topology?
MiddleDesignCommonYou design three integrations for a retail platform. First, a customer places an order and must immediately get an order number back. Second, a price change must reach 200 shop back-offices, some of which are offline at any moment. Third, an accounting system needs a full sales report every night. For each case decide between a synchronous API and an asynchronous message broker, and justify the choice from latency, coupling, and delivery needs.
You design three integrations for a retail platform. First, a customer places an order and must immediately get an order number back. Second, a price change must reach 200 shop back-offices, some of which are offline at any moment. Third, an accounting system needs a full sales report every night. For each case decide between a synchronous API and an asynchronous message broker, and justify the choice from latency, coupling, and delivery needs.
Order creation needs an immediate answer — use a synchronous API returning the order number. The price update fans out to 200 offline-tolerant shops with no reply — use a message broker. The nightly report is bulk and time-driven — use a scheduled batch export.
Common mistakes
- ✗Using a broker where an immediate synchronous reply is required
- ✗Fanning out with a synchronous call that fails on one offline node
- ✗Streaming a bulk nightly report instead of batching it
Follow-up questions
- →Why does a broker suit fan-out to offline consumers?
- →What confirms the customer's order actually succeeded?
MiddleDesignCommonTwo systems must be integrated, but each models a customer differently. One stores a single full-name field, a status code, and a country as a two-letter code; the other splits first and last name, uses a text status label, and stores the full country name. Produce the data mapping between them and describe how you document it so developers and testers can build and verify the integration.
Two systems must be integrated, but each models a customer differently. One stores a single full-name field, a status code, and a country as a two-letter code; the other splits first and last name, uses a text status label, and stores the full country name. Produce the data mapping between them and describe how you document it so developers and testers can build and verify the integration.
Build a field-by-field table: source field, target field, transformation rule. Split full name into first and last, translate the status code via a lookup, expand the country code via a reference table. Document defaults and invalid-value handling — this is the contract.
Common mistakes
- ✗Assuming fields align without transformation rules
- ✗Copying a code verbatim instead of a lookup translation
- ✗Omitting defaults and handling for missing or invalid values
Follow-up questions
- →How do you map a status label with no matching code?
- →Where should the country reference table live and who owns it?
MiddleTheoryCommonWhich errors must an integration spec describe, and how does a technical error differ from a business error?
Which errors must an integration spec describe, and how does a technical error differ from a business error?
The spec must cover technical errors (timeout, 5xx) and business errors (insufficient funds). A technical error is a transport failure, usually retriable; a business error is a valid rejection that must not be retried. Each needs a code, message, and action.
Common mistakes
- ✗Retrying a business error as if it were transient
- ✗Documenting only the happy path, no error catalog
- ✗Swapping the definitions of technical and business errors
Follow-up questions
- →Which HTTP status range fits a business rule rejection?
- →Why must a business error not be retried automatically?
MiddleTheoryCommonWhat is an ESB (enterprise service bus), and how does it differ from a plain message queue?
What is an ESB (enterprise service bus), and how does it differ from a plain message queue?
An ESB is a central hub that adds routing, translation, protocol adaptation, and orchestration. A message queue only transports messages between producer and consumer, without content-routing them. A queue is transport; an ESB is a platform on top.
Common mistakes
- ✗Treating an ESB and a queue as interchangeable
- ✗Thinking a plain queue does content-based routing
- ✗Missing that ESB logic is centralized in the bus
Follow-up questions
- →What risk does centralizing logic in the ESB create?
- →When is a plain queue enough without a full ESB?
MiddleDesignCommonYour system calls an external payment provider synchronously, but the provider sometimes does not answer within the timeout. The money may or may not have moved. In the integration spec, define what the caller does on a timeout — retry, compensate, or fail — and how you keep the outcome correct so a customer is never charged twice or left in an unknown state.
Your system calls an external payment provider synchronously, but the provider sometimes does not answer within the timeout. The money may or may not have moved. In the integration spec, define what the caller does on a timeout — retry, compensate, or fail — and how you keep the outcome correct so a customer is never charged twice or left in an unknown state.
A timeout means the result is unknown, not failed — never blindly retry a charge. Make it idempotent with a client key, so a safe retry hits the same charge, not a second one. If still unknown, query the provider's status or mark the payment pending to reconcile later.
Common mistakes
- ✗Retrying a charge with no idempotency key after a timeout
- ✗Assuming a timeout means the operation definitely failed
- ✗Leaving the payment in an unknown state with no reconciliation
Follow-up questions
- →How does an idempotency key make a retry safe here?
- →What does the pending state let you do that a hard fail cannot?
SeniorDesignCommonWhen designing an asynchronous exchange between systems, how would you think through error handling, delivery guarantees, and idempotency so a message is neither lost nor applied twice?
When designing an asynchronous exchange between systems, how would you think through error handling, delivery guarantees, and idempotency so a message is neither lost nor applied twice?
Decide where errors are detected and handled: the detecting system retries and self-heals, and/or alerts people to resolve it. Guarantee delivery with persistence, acknowledgements, and retries, plus a dead-letter queue. Make consumers idempotent via a unique message id.
Common mistakes
- ✗Treating delivery as guaranteed without persistence, acks, and retries
- ✗Skipping idempotency so a retried message applies twice
- ✗Leaving no logging/monitoring, making failures invisible
Follow-up questions
- →How does a unique message id ensure consumer idempotency?
- →What to do with a "poison" message that consistently fails?
JuniorTheoryOccasionalWhat is file exchange as a kind of integration, when is it still used, and what are its downsides?
What is file exchange as a kind of integration, when is it still used, and what are its downsides?
File exchange means one system writes a file (CSV, XML) to a shared folder or FTP, and another polls and reads it on a schedule. It still suits bulk nightly loads and legacy systems with no API. Downsides: high latency, no real-time, brittle parsing.
Common mistakes
- ✗Confusing file exchange with a real-time API call
- ✗Claiming it has no delivery or parsing risks
- ✗Saying file exchange is never used in modern systems
Follow-up questions
- →How would you make a file-based load restartable after a crash?
- →When is file exchange preferable to an API?
JuniorTheoryOccasionalMust a synchronous call always return a response, and is a stored-procedure call synchronous or asynchronous?
Must a synchronous call always return a response, and is a stored-procedure call synchronous or asynchronous?
Yes — a synchronous call blocks the caller until a response returns, so it is coupled to the callee's availability. Asynchronous means send-and-continue via a queue. A stored-procedure call is synchronous: the caller waits for its result.
Common mistakes
- ✗Thinking synchronous means fire-and-forget with no reply
- ✗Calling a stored-procedure invocation asynchronous
- ✗Believing an empty acknowledgement is not a response
Follow-up questions
- →How does a queue turn a call into an asynchronous exchange?
- →Why does a synchronous caller depend on the callee's uptime?
MiddleTheoryOccasionalHow does an ESB (enterprise service bus) differ from an ETL (extract-transform-load) tool, and when do you pick each?
How does an ESB (enterprise service bus) differ from an ETL (extract-transform-load) tool, and when do you pick each?
An ESB moves messages event by event in near real time, adding routing and transformation. An ETL tool extracts a batch on a schedule, transforms it, and loads it into a store — throughput over latency. Use an ESB for live integration; ETL for bulk moves.
Common mistakes
- ✗Swapping which tool is real-time and which is batch
- ✗Thinking ETL is a low-latency live transport
- ✗Believing only one of them can transform data
Follow-up questions
- →Which fits loading a nightly sales feed into a warehouse?
- →Can an ESB and ETL coexist in one landscape? How?
SeniorDesignOccasionalYou are asked to design an integration between two banking systems: one is the master source of customer data, the other must receive updates. Describe which questions you would work through, and in what order, to deliver a complete integration design.
You are asked to design an integration between two banking systems: one is the master source of customer data, the other must receive updates. Describe which questions you would work through, and in what order, to deliver a complete integration design.
Start from the business need and use cases, then name the systems and the initiator. Build the exchange regulation (source, target, trigger, payload), capture volume and frequency, specify the master source and mapping, then detail errors, delivery guarantees, and monitoring.
Common mistakes
- ✗Choosing the technology before the business need and data are understood
- ✗Skipping quantitative metrics (frequency, volume, growth)
- ✗Leaving error handling, delivery guarantees, and monitoring for the end as an afterthought
Follow-up questions
- →What should the exchange regulation table contain?
- →Why capture the expected volume and frequency before choosing the technology?
SeniorDesignOccasionalA partner will integrate with your system but hands you only a Postman collection of example requests — no written documentation, no schema, no error catalog. You must turn this into a proper integration contract your developers can build against. Describe how you reconstruct and document the contract from the collection, and which gaps you must actively fill by asking the partner rather than inferring.
A partner will integrate with your system but hands you only a Postman collection of example requests — no written documentation, no schema, no error catalog. You must turn this into a proper integration contract your developers can build against. Describe how you reconstruct and document the contract from the collection, and which gaps you must actively fill by asking the partner rather than inferring.
Treat the collection as examples, not a spec. Extract each endpoint, method, auth, and fields, then infer types and formats — marking every inference unconfirmed. Ask the partner what samples cannot show: field semantics, error catalog, limits, versioning. Confirm before build.
Common mistakes
- ✗Treating example requests as a complete final spec
- ✗Inferring the error catalog and limits instead of asking
- ✗Assuming a field seen once is always mandatory
Follow-up questions
- →What can examples never reveal about a field's constraints?
- →Why confirm the reconstructed contract with the partner first?
SeniorDesignOccasionalTwo systems must exchange customer updates, but they key the same person by different identifiers — the CRM uses its own numeric customer id, the billing system uses the contract number, and neither knows the other's key. There is no shared universal id. Design how the integration reconciles the two identities so an update from one system reliably lands on the right record in the other, and say how you handle a customer who cannot be matched.
Two systems must exchange customer updates, but they key the same person by different identifiers — the CRM uses its own numeric customer id, the billing system uses the contract number, and neither knows the other's key. There is no shared universal id. Design how the integration reconciles the two identities so an update from one system reliably lands on the right record in the other, and say how you handle a customer who cannot be matched.
Build a cross-reference table pairing both keys, so each id maps to the other. Populate it by matching on stable attributes like tax id, then keep it authoritative. Score fuzzy matches and review uncertain ones manually; an unmatched customer is quarantined, not force-merged.
Common mistakes
- ✗Assuming two different keys hold the same value
- ✗Auto-merging fuzzy matches with no review queue
- ✗Deleting or force-merging an unmatched customer
Follow-up questions
- →Which attributes make the most reliable matching keys?
- →How do later messages avoid re-matching from scratch?
SeniorDebuggingRareA web service on the enterprise service bus adds two new mandatory fields. What breaks, and what must change in the integration?
A web service on the enterprise service bus adds two new mandatory fields. What breaks, and what must change in the integration?
Every message now fails at the target: the service rejects requests missing the two mandatory fields, though senders are unchanged. Fix it by updating the bus mapping to supply the fields, bumping the contract version, and updating consumers and tests. Roll out with backward compatibility.
Open full question →Common mistakes
- ✗Assuming the bus auto-fills missing mandatory fields
- ✗Changing only the sender and skipping the bus mapping
- ✗Rolling out with no version bump or backward compatibility
Follow-up questions
- →Where could the bus source the new field values from?
- →How do you avoid losing in-flight messages during the change?
