What is composable architecture, and what is the honest trade?

Composable architecture means building a system by assembling independent services — each chosen because it is good at its job — rather than buying one product that does everything adequately. Swap any piece without rebuilding the rest.

That is a genuine capability and it has a bill attached. Every seam between two services is integration somebody writes, owns, and maintains, and the total of those seams is the cost of the flexibility. Whether the trade is worth it depends on facts about your organisation rather than on architectural preference.

What we'll cover

• What composable means in practice
• What you are buying
• The integration bill
• Where the seams should go
• The data problem
• When a suite is the better answer
• Evaluating a component
• Migrating towards it, without a rewrite
• Holding it together with CodeWords
• What to get right first
• Frequently asked questions

What composable means in practice

Independent services with APIs, each owning one capability — payments, search, content, identity, commerce.

Replaceable in principle, which is the promise and is truer for some components than others.

API-first, meaning the service's interface is the product rather than an afterthought bolted onto a user interface.

Assembled by you, which is the part that distinguishes it from buying a platform.

The terminology varies by industry — headless commerce, best-of-breed, modular architecture — and the underlying trade is the same everywhere.

What you are buying

Best-of-breed capability. Each component is chosen for being good, rather than tolerated for being included.

Replaceability. A component that stops meeting your needs can be swapped without rebuilding everything.

Negotiating position. A vendor who knows you could leave behaves differently from one who knows you cannot.

Independent evolution. Upgrading one component does not require a coordinated upgrade of everything.

Room for what is genuinely yours. The parts that differentiate your business are built rather than configured around somebody else's assumptions.

Those benefits are real, and every one is conditional on the integration between components being maintainable.

The integration bill

The part that does not appear in any vendor's comparison table.

Every seam is code. Two services that need to know about each other require something between them, and that something is yours.

It is not a one-off. Vendors change APIs, deprecate versions, and alter behaviour, and each change lands on your integration.

Failures multiply. With five services, the question "is the system up" has more possible answers, and the combinations are where surprising behaviour lives.

Debugging crosses vendors. A problem spanning two services is a problem where neither vendor is responsible and you are the only party who can see both.

Somebody has to own each seam, and unowned integrations are the ones that break during a vendor's routine update.

Count the seams before committing. Five components have up to ten possible pairwise connections, and while you will not build all of them, the number grows faster than the component count.

Where the seams should go

Around genuinely distinct capabilities, not around technical layers.

Where data has one owner. If two components both need to be authoritative for the same records, the boundary is wrong and you will be reconciling forever.

Where the vendor landscape is actually competitive. Composability is only valuable where alternatives exist; a component with one credible supplier is a dependency regardless of how cleanly it is separated.

Where change is likely. Separating something you expect to replace is worth the seam; separating something stable is paying for an option you will not exercise.

Not around your differentiator. The thing your business is actually good at should be yours, not a component you have integrated.

The data problem

The hardest part, and the one that determines whether the architecture stays coherent.

Each service holds its own data, so the complete picture of a customer exists nowhere.

Identity is the first casualty. The same person is a different record in each service, and reconciling them is ongoing work.

Decide ownership per field, explicitly, and write it down. Without that, two services both update an address and the last write wins arbitrarily.

Synchronisation drifts. Any duplicated field will diverge, and only a reconciliation check will tell you.

Reporting needs its own answer. Analytics across a composed system means a warehouse fed by every component, which is an additional system to build and run.

This is where most composable architectures deteriorate, not at the API boundaries, which are usually fine.

When a suite is the better answer

Worth stating plainly, because the honest answer for many organisations is a suite.

Small teams. Integration work is a fixed cost that a small team pays disproportionately.

Where the capability is not a differentiator. If your commerce experience is not what makes customers choose you, an adequate integrated one is fine.

Where the suite is genuinely good enough. Many are, and "good enough and integrated" beats "excellent and disconnected" more often than architectural discussions admit.

Where nobody will own the seams. Integration without ownership decays, and a decayed composable system is worse than a suite.

A hybrid is usually right. A suite for the commodity capabilities and separate components where you genuinely need the best — rather than a doctrinal commitment either way.

Evaluating a component

Does the API cover what the interface does? An API that is a subset of the product is a component you will hit the edge of.

What is the deprecation history? How often have they broken things, and with how much notice?

Can you get your data out, completely, in a usable form? This is the question that determines whether replaceability is real.

What are the limits — rate limits, volume limits, plan gates — and how do they behave as you grow?

Are webhooks reliable, with retries and signatures? Weak eventing pushes you to polling, which is a permanent tax.

Who else has integrated it? A component nobody has connected to your other components is one you are pioneering.

Migrating towards it, without a rewrite

Most organisations arrive here from a suite they have outgrown in one area, not from a blank page.

Replace one capability, the one where the suite is most clearly inadequate, and leave everything else.

Run both during the transition, with the suite still authoritative, until the replacement is genuinely working.

Move the data with the capability, which is the part people defer and the part that makes the change real.

Expect the seam you just created to be the hard bit, since the suite's internal integration was free and yours is not.

Measure whether it helped, against whatever motivated the change — if the new component is better and the integration cost exceeds the benefit, that is worth knowing before replacing a second one.

Do not commit to a wholesale migration up front. Each replacement is a separate decision with its own case, and organisations that decide to become composable in principle usually replace more than they should.

Holding it together with CodeWords

The seams are where the ongoing work is, and most of them are integration rather than product logic. CodeWords connects to more than 3,000 integrations and builds automations from a plain-language description.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which systems, what triggers it, and what should result.
3. Describe the exceptions: a service that is unavailable, a duplicate event, a record that cannot be matched between systems.
4. Connect each system once and reuse the connections.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What to get right first

A written record of which service owns which data, field by field, for anything that exists in more than one place. It is a short document, it is the thing that prevents the slow divergence that degrades composed systems, and producing it frequently reveals that a boundary is in the wrong place.

Two habits make the difference. Name an owner for every seam, since unowned integrations are the ones that break during a vendor's routine update and take days to diagnose. And build the reconciliation check alongside each synchronisation, because duplicated data always drifts and nothing else will tell you that it has.

Frequently asked questions

What is the real cost of composable architecture?

The integration between components — written, owned, and maintained by you, permanently, against APIs that change on vendors' schedules. It is the cost that appears in no comparison table and dominates the lifetime total.

Is best-of-breed better than a suite?

Not automatically. A suite is frequently the better answer for small teams, for capabilities that are not your differentiator, and anywhere nobody will own the seams. A hybrid is usually more sensible than a doctrinal commitment.

Where should boundaries go?

Around distinct capabilities where the data has a single owner and the vendor landscape is genuinely competitive. Not around your differentiator, and not around something stable that you will never actually replace.

Why do composable systems degrade?

The data, rather than the APIs. Identity fragments across services, duplicated fields drift, and no single system holds the complete picture. Deciding ownership per field and checking for drift is what prevents it.

How do I evaluate a component?

Whether the API covers everything the interface does, the vendor's deprecation history, whether you can export your data completely, how limits behave as you grow, and whether webhooks are reliable enough to avoid polling.

Is replaceability real?

Only if you can get your data out in a usable form and the seam is genuinely maintained. A component whose data export is incomplete is a dependency with a modular diagram, regardless of how clean its API is.

How do I do reporting across components?

A warehouse fed by each of them, which is an additional system to build and operate. It is the piece most often omitted from the plan and the one people notice fastest, because the reporting they had before stops working.

How do I move from a suite without a rewrite?

Replace one capability — the one where the suite is most clearly inadequate — run both until the replacement works, and move the data with it. Treat each further replacement as a separate decision rather than committing to a wholesale migration.

What surprises people about the first replacement?

That the seam is the hard part. The suite's internal integration was free and invisible; the equivalent between your new component and everything else is code you now own and maintain against somebody else's release schedule.

How many components is too many?

When the number of seams outgrows the people maintaining them. Five components have up to ten possible pairwise connections, and the seam count grows faster than the component count — which is the practical ceiling rather than any architectural one.

What should be built rather than bought?

Whatever differentiates the business. Composability is about assembling the commodity capabilities well so the effort goes into the part that is genuinely yours, and a differentiator assembled from somebody else's components is not one.

Related reading

• Microservices vs monolith
• Integration platforms
• API gateways