orchestrating five systems without middleware

date: May 20, 2024

Problem: Connect five systems: Medusa (commerce), Odoo (ERP), a custom Product Configurator, Strapi (PIM), and a Data Management Portal. Maintain data consistency across all of them. The traditional approach is complex middleware with sync failure handling, data inconsistency debugging, and brittle connections.

Solution: Event-driven architecture using Medusa's workflow engine. No middleware. No unnecessary data duplication. Each system owns its domain. Medusa coordinates without trying to own everything.

System Responsibilities

Medusa handles cart, checkout, order orchestration, customer accounts with organization links, and shipping calculations. Odoo (ERP) handles order fulfillment, inventory management, organization data, and shipping rules. The Product Configurator handles real-time price calculations, configuration validation, and customer-specific pricing. The Data Management Portal owns pricing rules, product configuration logic, and volume discount tiers. Strapi (PIM) manages product descriptions, material specifications, images, and documents.

Each system owns its domain completely. No overlap. No ambiguity about where data lives.

The Integration Pattern

Orders flow bidirectionally. Web orders go from Medusa to Odoo. Sales rep orders go Odoo to Medusa. This ensures consistency regardless of order source.

Every entity (customer, order, product) has both a Medusa ID and an Odoo ID. Systems reference each other through IDs, not tight integration. Replacing one system doesn't cascade everywhere.

Customer shipping data caches in Medusa, updated only when Odoo sends change webhooks. This makes checkout fast. No waiting on ERP queries. Shipping rules don't change every second, so caching them is safe.

Medusa workflows handle order placement: validate cart against configurator pricing, calculate shipping from Odoo data, create order in Medusa, send webhook to Odoo, listen for fulfillment updates. Built-in rollback if any step fails. No orphaned data.

Custom Pricing Integration

This was the complex part. Pricing depends on product configuration (material, size, quantity), customer organization, volume discounts, and special agreements. Four variables that all affect the final number.

The customer configures a product in the storefront. The Configurator calculates base price using DMP rules. DMP applies org-specific discounts. Price validation happens at checkout. Final price stores in the Medusa order. Order data syncs to Odoo with price locked.

Organization Accounts

We extended Medusa's customer model with a single field: organizationId. This links multiple buyers to the same company.

The result: shared order visibility across org buyers, organization-level pricing and promotions, company-specific product recommendations, unified shipping and billing rules. Single field extension. Significant B2B experience impact.

What Worked

Event-driven beats request-response. Webhooks mean systems don't wait on each other. Order placement doesn't block on Odoo. Fulfillment updates arrive asynchronously.

Cache what changes slowly. Shipping rules don't change every second. Cache them in Medusa, update only when Odoo signals changes. Distinguish frequent changes (cart data) from rare changes (shipping rules).

Validate at boundaries. Pricing calculations happen in the configurator, but Medusa validates before order creation. Catch inconsistencies early, before they become customer problems.

What We Learned

Middleware indicates unclear responsibilities. If you need complex middleware, that's a sign the architecture has problems. Clarify who owns what first.

Workflows prevent bug classes. Structured patterns for multi-step operations with rollbacks eliminate entire categories of failure modes. No more orphaned data.

ERP integration doesn't mean ERP ownership. Commerce platforms handle commerce better. Sync only what ERP requires. Don't try to make Medusa into an ERP or vice versa.

Read about this integration pattern in Medusa's ERP guide.

Technical implementation by the rb2 team. I worked on the architecture and integration patterns.