Integration style
Synchronous APIs for queries and commands, events for state change propagation.
Why. Each pattern where it fits.
Trade-off. Eventual consistency in downstream systems.
Integration and multi-application · AWS and Azure
API-led integration hub with an event bus, API gateway and iPaaS
A small number of governed APIs and an event backbone in front of many systems, so each application integrates once with the hub instead of with every other application.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- ACSC Essential Eight
- Australian Privacy Principles
- SA ISMF supplier expectations
- Australian regions
Architecture
- People and clients
- Network and edge
- Messaging, events and workflow
- Databases and data
- SaaS and business systems
- Security and identity
- Monitoring, audit and analytics
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
A client calls the gateway with an OAuth token. The gateway authenticates, rate-limits and validates against the published API contract.
The call is routed to a domain service that owns the business capability, such as customer or order.
When state changes, the service publishes an event (for example CustomerUpdated) to the bus, validated against a schema.
Subscribers receive the event: adapters and iPaaS flows that need to update other systems.
Adapters translate to each system's protocol and data model, handling retries, ordering and idempotency.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| API gateway (Amazon API Gateway, Azure API Management, Kong) | Authentication, throttling, versioning and analytics. | One front door means one place for policy and visibility. |
| Domain services | Own business capabilities behind stable contracts. | Consumers depend on the contract, not on the system behind it. |
| Event bus (EventBridge, Azure Service Bus or Event Grid, Kafka or MSK) | Publish-subscribe backbone with filtering and replay options. | Decouples producers from consumers. Kafka suits high volume and replay, managed buses suit most organisations. |
| iPaaS (MuleSoft, Boomi, Azure Logic Apps) | Pre-built connectors and mapping. | Faster for SaaS integration. Custom code is better for core logic. |
| Schema registry and API catalogue | OpenAPI, AsyncAPI and event schemas. | Contracts prevent silent breaking changes. |
| Dead-letter queues and replay | Capture failures. | Operations can fix and replay without developer involvement. |
| Secrets and certificates | Per-connection credentials. | Rotation without redeploy. |
| Observability | Traces across the hub. | Without correlation IDs integration issues are guesswork. |
Design decisions and trade-offs
Build vs iPaaS
iPaaS for SaaS connectors, code for domain logic.
Why. Avoid reinventing connectors and avoid burying logic in drag-and-drop flows.
Trade-off. Licence cost and two skill sets.
Bus technology
Managed event bus first, Kafka when volume or replay demand it.
Why. Operational simplicity.
Trade-off. Less control and different semantics than Kafka.
Governance
Contract-first with CI checks for breaking changes.
Why. Teams move independently without breaking each other.
Trade-off. Upfront design effort.
Well-architected pillars
Security
OAuth at the gateway, mTLS to back ends, secrets in a vault and least-privilege per connector.
Reliability
Queues and DLQs, idempotent consumers and circuit breakers on slow systems.
Performance
Cache reference data at the gateway, async for slow back ends.
Cost optimisation
Gateway requests, iPaaS licences and message volume.
Operational excellence
Runbooks for DLQ replay and a catalogue of owners per API and event.
Sustainability
Reuse domain services rather than building point-to-point copies.
Network, identity and data
Networking
Gateway public, everything behind it private. Connectivity to on-premises over VPN, Direct Connect or ExpressRoute. Egress to SaaS from fixed IPs where partners require allow-listing.
Identity and least privilege
Clients are registered with scopes. Service-to-service uses workload identity or mTLS. Each connector has its own credential with permissions limited to the operations it performs.
Data and encryption
Events carry identifiers and the minimum data, not whole records, so personal information is not copied to every subscriber. Classify event types and restrict subscription to those with a need.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Restrict administrative privileges | Separate roles for API publishers, platform admins and operators. Essential Eight. |
| Logging | Gateway and bus logs with correlation IDs for investigation. |
| Privacy | Minimal event payloads support APP 6 and APP 11. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOUnder an hour to redeploy from code
- Target RPONear zero for queued events
- Scaling and limitsManaged buses scale to high throughput. Check service quotas for rules, targets and payload size limits.
| Failure mode | Mitigation |
|---|---|
| A back-end system is down | Queue and retry. Circuit breaker returns a clear status to consumers. |
| Breaking change to an event | Schema compatibility checks in CI and versioned topics. |
| Duplicate or out-of-order events | Idempotent consumers and sequence numbers where order matters. |
| Gateway misconfiguration exposes an API | Policy as code and automated tests for auth on every route. |
Observability and runbooks
- Trace each request and event with a correlation ID.
- Alerts on DLQ depth, consumer lag and gateway 5xx.
- A dashboard of consumers per event so that retirement decisions are safe.
Cost drivers and levers
Gateway calls, bus events, iPaaS licences and data transfer.
- Cache at the gateway.
- Filter events at the bus.
- Retire unused APIs and flows.
- Batch low-urgency syncs.
Implementation and fit
Phased approach
- Pick two systems and one business event to prove the pattern.
- Publish the first contract-first API and event.
- Add the catalogue and CI checks.
- Migrate point-to-point integrations in order of risk.
Anti-patterns to avoid
- Point-to-point links between every pair of apps.
- Business logic hidden in mapping tools.
- Events that carry the whole customer record.
- No owner for each API.
When to use it
- Three or more systems exchanging data.
- Frequent changes to back-end systems.
- Partner and mobile channels needing stable APIs.
When not to
- Two systems and one simple sync.
- Teams without capacity to run governance.
More in integration and multi-application
Web, mobile and back office
Multi-channel API platform with a portal over several back-end apps
Web, mobile and staff back-office experiences on one API platform. A backend-for-frontend per channel and a micro-frontend portal let several applications look like one product without becoming one codebase.
Master data
Master data management and integration across HR, finance and CRM
Agree who owns each core entity (person, organisation, product, cost centre), publish the golden record to the systems that need it and reconcile the differences before they reach a report or an auditor.
Modernisation
Legacy system modernisation with the strangler fig pattern, APIs and RPA
Replace a legacy system one capability at a time. A routing facade sends each request to the old or new implementation, anti-corruption layers protect the new design and RPA covers the gaps until APIs exist.
Related insights
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.