Event-driven middleware for Australian businesses.

Durable. Idempotent. Auditable. Australian-hosted. From $40,000 deployed.

What event-driven middleware actually means

In an event-driven architecture, every change in any connected system fires a typed event. Events go to a durable bus. Other systems subscribe to the events they care about. Nothing is tightly coupled to anything else. When System A changes how it stores customer records, System B does not need to know; the event contract between them is what matters, and the event contract has not changed.

This is the architecture every mature engineering team converges on. Stripe runs on it. Shopify runs on it. AWS is built on it. The reason it is the destination architecture is simple: it survives. Systems fail, vendors change APIs, traffic spikes, networks misbehave. Event-driven systems handle all of it gracefully. Point-to-point integrations do not. A Zapier workflow with seven steps fails seven different ways; each one creates a quiet data-quality problem nobody notices until month-end reporting.

What changed in the last five years is that you no longer need an enterprise budget to deploy event-driven middleware. The patterns are well-understood. The open-source tooling is mature. The hosting costs are predictable. Nexus is event-driven middleware for businesses that need the architecture and not the enterprise price tag. The patterns are the same ones Martin Fowler and the broader industry have been writing about for years; the cost has come down enough that they are now accessible to mid-market businesses, not just enterprises.

The honest moment most agencies skip: most businesses do not need middleware. If you run two or three SaaS products and the native integrations between them work, building a middleware layer is over-engineering. The architecture earns its place when you have five-plus connected systems, when integration failures have started costing money, or when point-to-point complexity has crossed the line where adding the next integration is harder than the previous one. About one in three middleware discoveries we run ends with our recommendation to stay on point-to-point and fix the one integration that is actually broken. The answer “you do not need middleware” is just as valid as “you do.”

If you are running three or more core systems and you can feel the integration fatigue, call 0431 000 062.

Symptoms to look for

You probably need event-driven middleware when one or more of the following are true.

• Your integrations fail when one vendor has an outage. A Stripe blip, a Shopify rate limit, a Xero maintenance window, and your data flow stops. Nothing recovers automatically. Someone notices the next morning when the reports look wrong.
• You have point-to-point integrations growing without coordination. Each new connection is custom-built between two specific systems. The complexity is now N-squared. Adding the next system means writing N new integrations, each of which becomes its own maintenance burden.
• Your audit log is a series of email threads. When you need to know what happened with a customer or transaction, you have to ask three people and check four systems. The reconciliation question takes hours; sometimes it takes days. Sometimes the answer is “we cannot tell.”
• Retries are manual. A connection fails. Someone notices days later. Someone else runs an export, finds the missing records, and replays them by hand. The replay sometimes fails too, because the original integration had no idempotency. Data integrity has become a manual discipline.
• You cannot replay history. If you need to recompute last month’s data with a new business rule, your only option is a from-scratch reimport. Often that is not even possible because the source data has moved on. Once a wrong calculation has propagated to downstream systems, the fix takes weeks.
• Your Zapier or Make.com setup has become load-bearing. Workflows that were “just a quick automation” two years ago now move material amounts of money and data. Nobody documents them. The person who built them has left. The Zapier dashboard has 60+ active zaps. The business runs on no-code glue that nobody fully understands.
• You have been quoted enterprise middleware. Someone has put a MuleSoft, Boomi, or webMethods quote in front of you, and the licensing alone exceeds what the rest of your technology stack costs per year. The architecture is right; the price tag is wrong for your scale.

DIAGNOSTIC

If three or more apply, you have outgrown point-to-point integration. The next conversation is about whether to invest in a real middleware layer or wait for the next outage.

The architecture we deploy

Every event-driven deployment on Nexus follows the same three-layer pattern. The components are deliberately boring. Boring is the point.

Durable event bus

The bus is the core. Every state change becomes a typed, structured event. The bus stores events durably. Handlers can read, replay, and retry without breaking anything. If a handler is down for an hour, queued events wait. When it comes back, they replay in order. The bus does not lose events. The bus does not duplicate events. The bus does not reorder events. These three properties sound trivial; building them on top of point-to-point integrations is impossible.

Idempotent handlers

Every handler we write can safely process the same event twice. A retry is never destructive. A replay is never dangerous. This sounds obvious until you have a Zapier flow double-charge a customer because the original Zap and its retry both fired. Idempotency is the discipline that makes the rest of the architecture work; without it, durable retries become a hazard rather than a feature. Every handler we ship has an idempotency key and is tested under duplicate-delivery conditions before going to production.

Schema and versioning

Events have schemas. Schemas have versions. When a vendor changes their API or your business changes a rule, we version the event and migrate handlers. Nothing breaks silently. Nothing needs a full rewrite. The “we updated the integration and now last month’s data is corrupted” failure mode does not happen, because last month’s events still match last month’s schema, and the migration is explicit.

Observability and audit trail

Every event, every handler invocation, every retry, every schema migration is logged. The dashboard shows live event flow, lag, error rates, and replay status. When something does not look right, the investigation starts with a query, not a series of phone calls. When the auditor asks “show me how this transaction was processed end-to-end across all your systems”, the answer comes from the audit log in minutes, with the timestamps and the handlers and the data state at each step.

Connector library

Each connected system has a connector: the code that translates between the system’s native API and the event contracts on the bus. Connectors are versioned, tested, and shared across deployments. The Shopify connector that runs on one Nexus deployment is the same code running on every Nexus deployment. When Shopify changes an API, we update one connector and the fix flows to every client. No client pays separately for vendor-change maintenance.

Three engagement shapes

We structure middleware engagements one of three ways. All three start with discovery.

• Single integration on event-driven foundation. From $15,000. Replaces a point-to-point integration with a properly-architected event-driven equivalent. Lets you start small, prove the value, expand later. Best when one specific integration is the source of most of your reliability pain.
• Nexus deployment. From $40,000. Full middleware deployment, up to five connected systems, dashboard, 90 days of post-launch support. Best when you have several integrations to consolidate and the business case for the architecture is established.
• Run With Us. From $6,500 per month. Hosting, monitoring, on-call, continuous additions, security patching. The most common path post-deployment because middleware is infrastructure: it benefits from continuous care, not one-off maintenance.

Call 0431 000 062 to talk it through with an engineer.

Middleware deployments in production

Three middleware deployments. Two named clients, one confidential at client request. Reference calls available.

WesHealth, healthcare retail

• Problem: Three core systems (Dear Systems, Zenoti, WooCommerce) connected by a tangle of native plugins and Zapier flows. Inventory was the central pain: stock counts disagreed across systems daily, oversells were eating into customer trust, and the warehouse manager had a private spreadsheet that was the actual source of truth.
• Built: Event-driven middleware between Dear Systems, Zenoti, and WooCommerce. Inventory state changes in any one system propagate to the other two in near real time. Connectors versioned and shared with the wider Nexus deployment. Built over eight weeks.
• Result: Zero data-drift stockouts since go-live. 100% inventory parity between Zenoti and Dear. The warehouse manager’s private spreadsheet retired. The Zapier flows that had been propping up the integration retired with it.
• Stack: Nexus middleware, Dear Systems API, Zenoti API, WooCommerce REST API, PostgreSQL, AWS Sydney.

WHMA, multi-brand healthcare

• Problem: Multi-brand healthcare group with 180+ locations, three POS variants, Zenoti for booking, Shopify Plus for online retail. No single source of truth for products, customers, or inventory across the network. Each brand’s data was effectively a separate business; group-level reporting required manual consolidation each week.
• Built: Event-driven middleware between three POS variants, Zenoti, and Shopify Plus across 180+ locations. Single source of truth for products, customers, and inventory across the network. Cross-brand entity resolution (so that the same customer at two different brands is recognised as one person) handled at the middleware layer. Built over 18 weeks.
• Result: Group-level reporting now available in real time. Inventory parity across all 180+ locations. Cross-brand customer analytics now possible. The manual weekly consolidation process retired.
• Stack: Nexus middleware, three POS APIs, Zenoti API, Shopify Plus Admin API, PostgreSQL, AWS Sydney, custom entity-resolution engine.

A retail group, name confidential

• Problem: Retail group running 40+ active Zapier flows connecting Shopify, Klaviyo, Xero, and a custom warehouse system. Silent failures were endemic. The marketing team had stopped trusting their own email segmentation because the customer data was wrong by the time it reached Klaviyo. The CFO had a recurring monthly variance she could not explain.
• Built: Event-driven middleware between Shopify, Klaviyo, Xero, and the custom warehouse system. Removed 40+ Zapier flows in favour of typed, versioned events. Customer entity resolution at the middleware layer; marketing segments computed against the canonical customer view, not against Klaviyo’s incomplete copy. Built over 10 weeks.
• Result: Silent failures eliminated. Marketing trust in customer data restored. The CFO’s monthly variance closed. Zapier subscription retired, saving roughly $4,200 per year and removing a load-bearing tool nobody fully understood.
• Stack: Nexus middleware, Shopify Admin API, Klaviyo API, Xero API, custom warehouse API, PostgreSQL, AWS Sydney.

Who you will work with

No account managers, no offshore teams, no juniors learning on your project. The two engineers below scope, build, and ship the work. Middleware is invisible infrastructure when it is working; you want the people who understand it to be the same people who designed it. The engineer who designs your event contracts is the engineer who maintains them.

How we ship it

Middleware deployments run in four named phases. Each phase is fixed scope and fixed price.

Most middleware deployments run 6 to 10 weeks total. Larger deployments with more than five systems run longer.

Event-driven middleware FAQs