Integration Architecture Patterns: Choosing Between APIs, Events, Queues and Integration Platforms
Choosing integration patterns for business systems: direct APIs, webhooks and events, queues, integration platforms, batch files and escaping point-to-point.
How do you choose integration patterns?
Choose per integration flow: direct API calls when a system needs an immediate answer; webhooks or events when something has happened that other systems react to; message queues when work must be buffered, retried and processed reliably; an integration platform when connecting many SaaS tools with common patterns; and scheduled batch files when partners or legacy systems offer nothing else. Escape point-to-point sprawl gradually by cataloguing integrations, assigning owners, standardising patterns and monitoring every flow. There is no single right architecture.
This guide is for CTOs, architects and IT managers. For practical integration in Australian businesses, see API integration in Australia; for reliability patterns, API integration reliability.
Key takeaways
- Pick patterns per flow, by timing and coupling needs.
- Events and queues decouple systems; APIs give immediate answers.
- Avoid shared databases between applications.
- Catalogue every integration with an owner.
- Monitor flows end to end and reconcile data.
Patterns compared
| Pattern | Use when | Watch for |
|---|---|---|
| Direct API call | Immediate answer needed (stock, price, validation) | Coupling, timeouts, rate limits |
| Webhooks | A SaaS app notifies you of changes | Signatures, retries, out-of-order delivery |
| Events (publish/subscribe) | Many systems react to the same business event | Event design, schema versioning |
| Message queue | Reliable, buffered work between two systems | Dead letters, idempotent consumers |
| Integration platform (iPaaS) | Many SaaS connections with common patterns | Licence costs, complex logic limits |
| Batch files | Legacy or partner systems with no API | Latency, file validation |
| Shared database | Avoid between applications | Tight coupling, unclear ownership |
Escaping point-to-point sprawl
- List every integration: source, target, data, trigger, method, owner, failure handling.
- Identify the core business events (order placed, customer updated, invoice paid).
- Name a system of record per entity; see master data management.
- Introduce standard patterns: an event bus or queue for events, an API layer for queries.
- Move the most fragile or most-changed connections first.
- Add monitoring, alerting and reconciliation for every flow.
- Retire old connections once replacements are proven.
Designing events well
Name events after business facts in the past tense, such as OrderPlaced, include an identifier, timestamp and version, and decide whether events carry full data or a reference consumers fetch. Version event schemas so consumers can upgrade at their own pace. Make consumers idempotent, because events can be delivered more than once and out of order. See event-driven architecture and queue architecture for ecommerce examples.
Governance
Keep an integration catalogue, assign owners, store credentials in a secret manager, document data contracts, and review new integrations against the standard patterns. Monitor delivery, latency and error rates, and reconcile key totals, such as orders in ecommerce versus ERP, daily. See API versioning for managing change.
Hypothetical example: a wholesaler with ten systems
This example is hypothetical. A wholesaler had grown to about 25 point-to-point scripts between ecommerce, ERP, CRM, warehouse, accounting and a marketplace. Failures were found by customers. The team catalogued every flow, introduced a queue-backed event for 'order placed' that the ERP, warehouse and CRM consumed independently, used the existing iPaaS for simple SaaS-to-SaaS syncs, kept direct API calls for live stock checks, and added a dashboard and daily reconciliation. Old scripts were retired one at a time.
Common mistakes
- One pattern forced on every flow.
- Events without versioning or idempotent consumers.
- No owner or monitoring for integrations.
- Replacing everything at once.
- Shared databases used as integration points.
Related guides
- API integration in Australia for connecting business systems.
- Ecommerce webhooks for receiving events reliably.
- Data engineering for growing businesses for reporting pipelines.
- Customer data integration for sync and identity.
- Low-code vs custom software for integration platforms vs code.
Conclusion
Good integration architecture matches each flow to the right pattern, gives every integration an owner and monitoring, and moves away from point-to-point sprawl step by step. Standardise patterns, design events carefully and reconcile data.
Integrations becoming fragile?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on system integrations and APIs and workflow automation. If it would help to map and simplify your integrations, we are happy to talk it through.
Common questions.
Nothing at small scale. As systems grow, each new connection adds custom code, credentials and failure points; the number of connections grows quickly, nobody has a full picture, and changing one system breaks others. The problem is unmanaged growth, not direct connections themselves.