Composable commerce Swap parts. Not the whole shop.

Composable commerce means search, PIM, CMS or pricing run as separate services connected through APIs. We pull them out of your existing shop one at a time, where it pays off, and leave the rest running.

Discuss your architecture

When it pays off

Not every monolith needs to be taken apart.

Worth it if

  • one part of the shop keeps slowing you down, such as search or product data,
  • several teams should ship independently of each other,
  • you want to replace one building block without touching the rest.

Probably not if

  • your shop runs stably and rarely changes,
  • nobody is there to run five services instead of one.

Monolith? Looks great in a museum.

We pull out one building block after another. The shop keeps running in the meantime.

Discuss your architecture
Concrete block next to colorful wooden toy blocks

Typical setup

Four layers. You choose the products.

  • Experience

    Headless frontend or PWA, CMS, search, personalisation.

  • Domain services

    Cart and checkout, prices and promotions, catalog and PIM, orders.

  • Data

    Events between services, data warehouse, AI services.

  • Infrastructure

    API gateway, access rights, edge caching, monitoring across all services.

Magento can stay one of the services, for example for prices, customers and orders.

Connections

Decoupling is easy. Connecting reliably is the work.

  • Events instead of direct calls

    When a price changes in the ERP, the shop learns about it through an event. If a service is briefly down, nothing gets lost.

  • Workflows with retries

    Orders, approvals and returns run as workflows with timeouts, retries and manual steps where needed.

  • One entrance for the frontend

    An API gateway handles authentication and rate limits and gives each channel the response it needs.

  • Contracts between services

    Every interface is described and tested. An update in service A does not silently break service B.

Operations

Without clear ownership modularity turns into chaos.

  1. One owner per service

    With a runbook and an escalation path. No “nobody does that”.

  2. Contract tests

    Run with every release and show whether a change hits another service.

  3. Safe rollbacks

    Feature flags and gradual releases, so a bug only affects some users.

  4. Budgets per interface

    Response time and cost have a limit. If it is exceeded, monitoring speaks up.

Common questions

What teams want to know beforehand.

How is this different from a monolith?
A monolith bundles catalog, checkout, search and CMS in one piece of software. With composable, each service does one job and talks to the others through APIs. That way you can replace or scale one part without touching the rest.
Do we have to rebuild the shop completely?
No. It usually starts with a single service, for example search or the PIM. The rest of the shop keeps running while the new service gradually takes over.
When is it worth it?
When several teams work on the shop and block each other, or when one part of the system slows everything else down. For a small, stable shop it is usually too much.
How long does the rebuild take?
That depends on which service you pull out first and how much depends on it. We give a reliable estimate after looking at your shop and integrations, not before.
What does it cost?
The main cost lies in integration and in running several services, not in licenses. That is why we recommend starting with one limited building block.

Which building block slows you down? That is where we start.

Plan a composable roadmap