Technology
APIs and integration
Choose synchronous, event, batch and workflow patterns according to consistency, latency, failure and ownership boundaries.
Page purpose
Evaluate APIs and integration by architectural fit and operating consequence, not popularity.
API and integration technology expresses authority across system boundaries through commands, queries, events and transfers. A contract includes semantics, identity, timing, compatibility and failure behavior; a schema alone leaves the most consequential coupling implicit.
Synchronous calls exchange immediacy for temporal coupling. Events exchange producer independence for delivery, ordering and reconciliation complexity. Batch and file transfer can provide efficient, inspectable boundaries. Selection follows consistency and recovery needs rather than a preferred transport or integration product.
Fit criteria
Criteria to prove before adoption.
- Which domain owns each state change and which systems may only consume it?
- What consistency, latency and failure behavior does the business transaction actually require?
- Which contract changes must remain backward compatible, and for how long?
- Where should orchestration live, and who owns cross-system recovery?
Intended role
The role the technology should perform.
- Interaction styles aligned to consistency, timing and coupling requirements.
- Contracts whose semantics and compatibility can evolve without hidden coordination.
- Failure boundaries with explicit retry, duplicate, ordering and compensation behavior.
- Least-authority access and data exposure at every interaction boundary.
Engineering patterns
Decisions that make the choice operable.
- Interaction-style matrix for command, query, event, batch and managed transfer patterns.
- Contract style guide covering semantics, identity, errors, idempotency and correlation.
- Compatibility, versioning and deprecation policy by contract criticality.
- Security profile for workload identity, authorization scope, secrets and data minimization.
- Failure-semantics test catalogue for delay, duplication, reordering, partition and partial completion.
Controlled adoption
Proving fit before scaling.
- Locate command authority and observation needs before drawing an interface.
- Select interaction style from consistency, latency, volume and outage-tolerance requirements.
- Specify business semantics, authorization and failure behavior alongside the payload.
- Make compatibility and deprecation constraints executable through consumer and provider tests.
- Instrument correlation and reconciliation so technical delivery can be distinguished from business completion.
Technology limits
When does complexity exceed value?
- Turning a local failure into a cross-enterprise outage through synchronous dependency chains.
- Exposing excessive data or authority through broad service credentials.
- Assuming event delivery equals successful business processing.
- Accumulating permanent compatibility layers because deprecation has no owner.
Operating signals
Signals of a production capability, not a demonstration.
- Compatibility checks passing across supported producer and consumer versions.
- Duplicate, reordered and partial-flow scenarios producing the specified business result.
- Authorization scopes and exposed fields relative to the minimum contract need.
- Correlation coverage from initiating command to final reconciled state.
Decision questions
Engineering questions before choosing a tool.
When is an event preferable to a synchronous API?
An event fits when the producer can publish a fact without requiring an immediate consumer result, and when consumers can handle delivery delay, duplication and eventual reconciliation.
How should a contract evolve?
Prefer additive, semantically compatible change within a supported version. A breaking change needs an explicit migration window, consumer evidence and a deprecation owner.