Software-to-Software Integration Patterns

A Practical Guide to Integration: Choosing Between APIs, Event Bus, or iPaaS

Integration is the work behind the work. The board sees Salesforce, SAP, and a customer-360 dashboard. Your engineers see a 2am pager when a Shopify webhook retries seven times against an SAP B1 endpoint that quietly went read-only for month-end. Finance sees a close that slipped two days because an iPaaS connector silently dropped 142 invoices when a field was renamed upstream. The CMO sees a customer-360 view that is, on most days, a polite lie — the customer record from CRM disagrees with the order record from commerce, and nobody can tell you which is correct without a five-person Teams call.

Every mid-market Australian business hits this wall around the same time: when you have 8–15 systems of record and the cost of notintegrating them starts showing up on the P&L. The question is no longer whether to integrate — it is which pattern, and the wrong pattern compounds for years. This article is for the tech decision makers to help decide between four real options.

The four patterns you actually choose between

There are dozens of integration “styles” in textbooks. In practice, an Australian mid-market team is choosing between four. They are not equivalent, and they degrade under load in different ways.

Point-to-point API integration

The default. System A calls system B's REST or GraphQL endpoint directly. One contract, one network hop, synchronous response.

• Latency budget: lowest of the four when both systems are healthy — typically 50–300ms round trip on AWS within ap-southeast-2.
• Coupling:tight. A's release cadence is now coupled to B's API stability. Versioning discipline matters.
• Throughput: bounded by the slowest endpoint. No buffer.
• Schema evolution: painful past three or four consumers. Breaking changes require coordinated deploys.
• Vendor lock-in: low — REST and OpenAPI are portable.
• AU compliance: straightforward if both endpoints sit in ap-southeast-2 (Sydney) or ap-southeast-4 (Melbourne). APP 11 (security of personal information) obligations are easier to evidence — and Privacy Act s13G civil-penalty exposure (now up to A$50M / 3× benefit / 30% of adjusted turnover for body corporates) is reduced — because the data path is auditable end-to-end.

Point-to-point works beautifully up to about six systems. At seven it becomes O(n²) connections and the dependency graph starts owning you instead of the other way around.

Event bus

A central broker (AWS EventBridge, Kafka, RabbitMQ, Azure Service Bus). Producers publish events; consumers subscribe to what they care about. Producers don't know who's listening.

• Latency budget: EventBridge end-to-end latency is now ~130–230ms at p90/p99 since AWS's late-2024 optimisations (down from ~500ms previously). Suitable for most near-real-time paths; still not for sub-50ms synchronous requirements.
• Coupling: loose. Producers and consumers evolve independently as long as the event schema holds.
• Throughput: high. EventBridge custom buses handle 10,000+ events/sec per account with quota increases; Kafka scales further if you can run it.
• Schema evolution: the hardest part. Schema registries (EventBridge Schema Registry, Confluent Schema Registry) are non-negotiable past five producers.
• Vendor lock-in: moderate. EventBridge is AWS-specific; Kafka is portable but operationally heavy.
• AU compliance: EventBridge runs in ap-southeast-2 and ap-southeast-4. Data residency is enforceable per-bus. Consumer Data Right (CDR) for banking and energy is live and works well with event-driven patterns because CDR data flows are inherently asynchronous; non-bank lending joins CDR scope in July 2026, telco remains on pause (as of May 2026 — verify against the latest cdr.gov.au rollout schedule).

Event buses earn their keep when you have more than two producers of the same business fact (e.g., “customer updated” comes from CRM, billing, and the call centre).

iPaaS (integration platform as a service)

Workato, Boomi, MuleSoft, Tray, Celigo. A SaaS layer with pre-built connectors, a visual flow builder, and a runtime that hosts your integrations.

• Latency budget: workflow-dependent. Most iPaaS flows run in 1–10 seconds. Not for real-time paths.
• Coupling: the connectors are tightly coupled to vendor APIs; your business logic sits in the iPaaS layer, decoupled from underlying systems.
• Throughput: licensing-bound. Vendors typically meter on “task runs” or “API calls” — costs compound fast at high volume.
• Schema evolution: managed by the vendor for stock connectors, your problem for custom ones.
• Vendor lock-in: high. Migrating off Workato or Boomi is a 6–18 month project.
• AU compliance: check carefully. Several iPaaS vendors process data in US or EU regions by default. Boomi and Workato offer AU-region runtimes — confirm in writing for Privacy Act and CDR-regulated workloads.

iPaaS earns its place when business users (not engineers) need to own integrations —typical in finance and ops teams.

Custom service mesh

Istio, Linkerd, or AWS App Mesh sitting in front of dozens of internal microservices. Handles service discovery, mTLS, traffic shaping, observability.

• Latency budget: adds 1–5ms per hop. Negligible if your service count justifies it.
• Coupling: loose by design.
• Throughput: limited only by the underlying compute.
• Schema evolution: orthogonal — mesh handles transport, not contracts.
• Vendor lock-in: low if Istio or Linkerd; moderate if App Mesh.
• AU compliance: mTLS everywhere plus centralised policy supports the network segmentation outcomes that sit alongside the ASD Essential Eight controls — and supports the multi-factor authentication requirement for administrative paths via mesh policy. The Essential Eight strategies themselves (application control, patching, MFA, admin privileges, OS patching, macros, hardening, backups) sit at the host and identity layer; the mesh evidences enforcement of policy at the network and identity boundary.

A service mesh below 30 internal services is almost always over-engineering. We see it work above 50, struggle for ROI between 30 and 50, and burn teams below 30.

A decision matrix

Score each row against your situation. Higher = better fit. The pattern with the highest column total is usually right, but the individual scores matter — a zero on compliance can veto a winning total.

A note on using this honestly: if you score iPaaS at 4 but the AU compliance question lands at 3 because the vendor processes in us-east-1, the 3 is the answer. Compliance failures don't average out.

Concrete example: a 4-system integration on AWS (composite)

The following is a composite case — drawn from mid-market wholesale and industrial-supply engagements across India and the United States that we cannot name individually under NDA. The topology and integration patterns are representative; treat it as a worked architecture, not a logo reference. We show the AWS region as ap-southeast-2 (Sydney) for the Australian reader; the underlying engagements ran in their own regions.

An India-based industrial supply company runs on four systems of record:

• Salesforce — accounts, opportunities, quotes
• SAP Business One — financials, inventory master, purchase orders
• Shopify Plus — B2B portal for repeat-order customers
• Custom WMS — Node.js application on EC2, manages warehouse pick/pack across three sites

The integration goals: a single customer-360 view, real-time inventory across all channels, automatic order routing from Shopify into SAP B1 with WMS notification, and a daily reconciliation feed into the data warehouse.

The AWS-native architecture

In plain text for screen readers: Producers (Salesforce, SAP B1, Shopify Plus, custom WMS) publish into a single EventBridge custom bus in ap-southeast-2 — either via API Gateway webhooks, a Lambda poller, or a direct SDK call. EventBridge fans events out to Step Functions (orchestration) and transform Lambdas. Transform Lambdas read and write a DynamoDB idempotency table with a 7-day TTL, then drop into per-consumer SQS queues. Consumers back-publish into Salesforce, SAP, or the WMS. Each SQS queue has a DLQ wired to CloudWatch alarms.

The pattern in words:

• EventBridge custom bus is the backbone. Every system publishes business events ( OrderCreated, InventoryAdjusted, CustomerUpdated) onto a single bus in ap-southeast-2.
• A scheduled Lambda poller (EventBridge Scheduler, 30-second cadence) pulls deltas from the SAP B1 Service Layer and publishes them to the bus; SAP B1 has no native EventBridge source, and EventBridge Pipes only natively polls SQS/Kinesis/DynamoDB Streams/MSK/MQ/self-managed Kafka, not SAP.
• Step Functions Standard workflows handle the order-routing orchestration: receive OrderCreated from Shopify, validate against SAP inventory, reserve stock in WMS, write the sales order back into SAP B1, update Salesforce opportunity stage. Standard (not Express) because the workflow runs 30–120 seconds with human-approval branches for credit-hold exceptions.
• Lambda functions sit on every EventBridge rule for schema transformation. Source-of-truth schemas are versioned in EventBridge Schema Registry.
• DynamoDB idempotency table with TTL of 7 days keys every inbound webhook by its event ID. Re-deliveries hit the table, return 200 OK, no downstream effect. This is the single most important component for production stability.
• SQS queues sit between EventBridge and each terminal consumer for buffering, retry, and DLQs. Each DLQ has a CloudWatch alarm that pages duty engineer via PagerDuty.

Total monthly AWS spend at this volume (~600k events/day across the bus, ~12k Step Function executions): roughly US$1,200–US$1,600, before data egress. The previous iPaaS-based solution on the largest of the three reference engagements cost US$2,800/month on a 5-year contract. AWS bills in USD globally; these figures exclude egress, NAT gateway, and third-party SaaS.

Failure modes we actually see

These are not theoretical. Every one of these has shown up in an AU production system in the last 24 months.

1. Idempotency leaks under retry storms. A Shopify webhook fails to receive a 200 within 5 seconds because Lambda cold-started. Shopify retries. The transform Lambda processes both. SAP gets two purchase orders. Mitigation: idempotency key in DynamoDB on inbound, checked beforeany side effect. Use the webhook's native event ID where available; generate a content hash where not.

2. Schema drift breaking downstream consumers. Salesforce admin renames a custom field. The CRM-published event still validates against the registered schema (the field was optional). A downstream Lambda in the marketing automation flow assumes the old name, silently emits NULL into the data warehouse for 11 days before anyone notices. Mitigation: schema registry with consumer-contract testing, plus CloudWatch metric filters on “field-missing”warnings inside transform Lambdas.

3. Cost surprises from EventBridge custom buses at scale.EventBridge bills US$1.00 per million custom events ingested, an additional US$0.05 per million for cross-account delivery, and a further US$1.00 per million for cross-region replication via global endpoints (plus inter-region data transfer at standard AWS rates). At 1B events/month that's a US$1,000 ingestion floor —but the killer is downstream invocations: rule matching itself is free, and each matching rule fans out to its targets where each target invocation incurs the target service's cost (Lambda invocations, SQS messages, Step Functions transitions). A poorly-scoped rule (source: *) on a busy bus that fans out to expensive targets can 10x your bill at the target layer, not the bus layer. Mitigation: tight source and detail-type filters on every rule, target-cost dashboards per rule, monthly rule audits.

4. iPaaS vendor lock-in compounding silently. Year one, Boomi looks great — 11 integrations live in 90 days. Year three, you have 87 integrations, 23 custom connectors, and the renewal quote is up 38%. Migration estimate: 14 months and US$900k (composite figure across the three reference engagements). Mitigation: keep business logic in code (Lambda, Step Functions) wherever an engineer would own it. Reserve iPaaS for flows where a finance ops analyst genuinely owns the change cadence.

5. The synchronous integration that should have been async. Salesforce calls a Lambda that calls SAP that calls the WMS. End-to-end p99 is 18 seconds. Salesforce times out at 10. Sales reps blame “the system” and stop using the integration. Mitigation: any call chain with three or more synchronous hops is a smell. Replace with event publication + status callback, or use Step Functions with a wait-for-callback pattern.

Cost reality in USD

These are order-of-magnitude estimates for AWS-native patterns running in ap-southeast-2. They include compute, EventBridge/SQS/DynamoDB, and modest CloudWatch — they exclude data egress, NAT gateway, and any third-party SaaS (iPaaS, Datadog, etc.). AWS bills in USD globally; convert to your local currency at the rate that matters on procurement day.

Three honest caveats. First, these are estimates from real engagements with names removed — your mileage will vary by 30–50%. Second, the iPaaS row reflects the licence floor; many AU mid-market deployments sit at the high end because vendors price on task runs, not events. Third, the assumptions behind these numbers: average 2KB payload, p50 Lambda duration 200ms at 512MB memory, single-region ap-southeast-2, no NAT gateway hairpin egress, and downstream targets sized to the workload (not over-provisioned).

What we recommend

Across our integration practice — mid-market engagements across India and the United States over the last seven years — the defaults that have held up:

• Default to EventBridge for events + Step Functions for orchestration. AWS-native, ap-southeast-2 resident, audit-trail-ready for Privacy Act and CDR. Cheaper than iPaaS above ~50k events/day and far cheaper above 1M. Engineers can own it; the patterns are well-documented.
• Use iPaaS only when business users own integrations. If a finance ops manager genuinely changes the flow monthly, Workato or Boomi earns its licence. If engineering owns it, iPaaS is a tax.
• Avoid bespoke service mesh unless you have ≥50 services. Below that, ALB + Cloud Map + structured logging covers 90% of the value at 10% of the operational cost.
• Build idempotency in from day one. DynamoDB with a 7-day TTL, keyed on event ID. Non-negotiable.
• Treat schemas as code. Schema registry, versioned, with consumer-contract tests on every PR. The cheapest thing you will ever do, and the one most often skipped.

For most mid-market businesses, the destination architecture looks like the composite example above. The journey there is usually 6–9 months from a point-to-point spaghetti baseline, sequenced one business domain at a time.

FAQ

Is REST API still relevant in 2026?

Yes — overwhelmingly. REST remains the lingua franca for system-to-system integration, with OpenAPI 3.1 as the contract format. GraphQL has earned its place for client-driven aggregation, and gRPC for internal service-to-service. But for cross-boundary integrations (vendor to customer, partner to partner) REST + OpenAPI is still the path of least resistance and the format every iPaaS, every SDK, and every architect already speaks.

When should I use GraphQL instead?

When a single client needs to compose data from multiple backend services and the over-fetch problem of REST hurts measurably. Customer-facing mobile apps and React frontends with diverse view requirements are the strongest cases. For system-to-system back-end integration, GraphQL adds complexity (schema federation, N+1 query handling) without proportionate value —stick with REST or events.

How do I integrate legacy SOAP services?

Wrap them once. Deploy a Lambda or container-based adapter that exposes a REST or event interface and translates to SOAP underneath. Cache WSDL metadata. Never expose SOAP further into your architecture than that single adapter. Australian government and banking integrations still mandate SOAP in places — this wrap-once pattern keeps the rest of your stack clean.

What about Kafka vs EventBridge?

EventBridge wins for mid-market: serverless, ap-southeast-2 resident for AU workloads, integrated with 200+ AWS services, no cluster to operate. Kafka wins above ~50,000 events/sec sustained, or when you need event replay across long windows (days to weeks), or strict ordering guarantees within a partition. Below that throughput, the operational overhead of MSK or self-managed Kafka rarely justifies the choice.

Do I need a service mesh?

Probably not. If you have fewer than 30 internal services, ALB plus structured logging plus AWS X-Ray covers the observability and routing needs. Service meshes shine above 50 services where mTLS, traffic splitting, and fine-grained policy become daily concerns. Between 30 and 50, the decision is contextual — usually no.

Talk to an integration architect

If you're scoping a real integration programme and want a second opinion on pattern fit, AWS cost envelope, or AU compliance posture, we offer a 30-minute architecture review — no slides, no sales pitch, a working conversation with the person who would lead the build. Book a session with us at brainstacktechnologies.com/contact and ask for an integration architecture review.

By Naveen Khanna — Founder, Brainstack Technologies.
Reviewed May 2026.