Engineer Architecture study materials
Engineer Architecture study resources

Engineer Architecture: Integration, Interfaces, and Interoperability

Engineer Architecture · Work through your exam, one topic at a time.

All guide sections

Integration, Interfaces, and Interoperability

What this domain tests

This domain tests how systems exchange meaning, not just bytes: integration styles, contract design, message semantics, versioning, and the organisational side of interoperability.

Core rules

  • Choose the integration style by coupling: file transfer (lowest coupling, highest latency), shared database (tightest coupling, avoid across domains), remote procedure call (simple, temporally coupled), messaging (decoupled, asynchronous, eventual consistency).
  • Contract-first: define the interface (OpenAPI for HTTP, AsyncAPI for events, protobuf for gRPC) and let both sides generate code. Design contracts so unknown fields are tolerated by consumers.
  • State delivery semantics explicitly. At-least-once plus idempotent consumers is the practical default; exactly-once is broker-scoped and breaks once external side effects exist.
  • Interoperability has layers: technical (transport and syntax), semantic (shared meaning, code lists, units), and organisational (process and legal agreement). Most failures are semantic.
  • Version compatibly: additive changes are backward compatible; removing or retyping a field is breaking. Prefer tolerant reader plus explicit versioning.

Worked example

Two systems exchange order events. The naive answer is a synchronous REST call at order creation, so a downstream outage blocks sales. Better: publish an event to a topic; the consumer persists an idempotency key (order ID plus event version), applies business rules, and tolerates duplicates. A canonical schema with a shared code list resolves the semantic mismatch where one system's "shipped" means dispatched and the other's means delivered.

Traps

  • Using a shared database as an integration mechanism and calling it decoupling.
  • Assuming distributed transactions; sagas with compensation are the realistic answer.
  • Ignoring ordering requirements - partitioning by key is the usual fix.
  • Confusing orchestration (a controller knows the flow) with choreography (participants react to events).