Architecting an Event-Driven Business Ecosystem

The Context

A group of related businesses rarely fits inside one codebase. TORA & TORY runs as a set of separate applications, each with its own database: an e-commerce storefront, a business operations management system, and applications for affiliated companies.

Independence is useful. Each application can be developed and deployed on its own, and its data model stays private to it. It also removes the shortcut of reading another system’s tables. Anything that has to be shared (an order, a stock level, a customer record, a financial figure) must cross an explicit boundary.

The engineering problem is keeping those applications working as one business without collapsing them into one system.

The System

The ecosystem is a set of cooperating applications rather than a monolith:

• An e-commerce storefront, developed independently by me.
• A business operations management system that integrates multiple affiliated companies.
• Affiliated company applications, each backed by its own database.

Applications communicate through APIs and through asynchronous messaging built on queues and webhooks. The interactive diagram above maps these pieces and how they relate.

Confirmed vs. conceptual. Separate applications, separate databases, API integration, queues and webhooks, and BullMQ with Redis are confirmed implementation facts. The exact arrangement of services, their count, and their hosting are not described here, and the diagram does not claim them.

The Integration Layer

Two communication styles carry most of the weight in this kind of system.

REST APIs are synchronous request-and-response. They are the right tool when one application needs an answer from another, or needs to ask it to change data it owns. The owning application stays the single writer of its own database.

Webhooks are the opposite direction: push-based events. An application announces that something happened, and interested systems react without polling for changes.

Used together, APIs handle direct interactions while webhooks broadcast events. Specific endpoints, event types, and payloads are internal and intentionally omitted.

Asynchronous Processing

Reacting to an event often means calling another application, and that call can be slow or temporarily unavailable. Doing it inside the original request would tie one application’s responsiveness to another’s health.

BullMQ with Redis moves that work out of the request path. An incoming event becomes a job on a Redis-backed queue, and BullMQ workers process it independently. The triggering application can acknowledge the event and continue.

// Pseudocode — illustrative only, not production source.
on webhook event:
    validate event
    enqueue job(event)
    respond immediately

worker for queue:
    take next job
    call target application's API
    mark job complete or failed

Business Workflows

On top of this foundation sit the business domains the system exists to serve:

• Inventory: stock information for the products the business sells.
• Orders: orders originating from the storefront and moving through the business.
• Customer records: customer information held by the applications that need it.
• Financial operations: the money side of the business.
• Reporting: visibility across the operation.

The point of the integration layer is that these domains are not trapped inside a single application’s boundary.

Engineering Ownership

This was owned end to end. I independently developed the TORA & TORY storefront, built the operations management system that integrates the affiliated companies, and made the architectural decisions that connect the applications: how they expose APIs, how events travel, and where asynchronous processing belongs. I also own production engineering for the system, in my role as Head of Technology.

Technical Reflection

The points below are general trade-offs of event-driven integration. They are not statements about how this specific system implements any of them.

General consideration: consistency. Separate databases mean state converges over time rather than updating atomically. Workflows need to tolerate a short window in which applications disagree.

General consideration: duplicate and failed deliveries. Webhook and queue systems commonly deliver events more than once, or fail partway. Handlers are usually designed so that repeating work is safe, and failures are made visible.

General consideration: contracts. Once applications are independent, API and event shapes become contracts. Changing one needs the same care as changing a public interface.

General consideration: observability. Asynchronous flows are harder to follow than a single request. Tracing an event across applications and queues is a design concern from the start.