Composable Architecture: MACH Principles, Packaged Business Capabilities, and API Orchestration [2026]

The average enterprise runs 975 SaaS applications. Most of them cannot share data, cannot be replaced without a rewrite, and are locked into vendor upgrade cycles that have nothing to do with the organization's own roadmap. Composable architecture is the engineering response to this problem: build systems from replaceable, API-connected capabilities so that individual components can change without disrupting everything connected to them.

This guide covers the composable architecture pattern in full: MACH principles, Packaged Business Capabilities (PBCs), API orchestration layer design, best-of-breed selection criteria, composable commerce architecture, and realistic migration strategies from monolithic systems. By the end, you will have a clear framework for evaluating whether composable architecture applies to your context and how to implement it incrementally.

Composable Architecture: What It Actually Means

Composable architecture is not microservices with a marketing name. The distinction matters.

Microservices decompose a system along technical boundaries — each service owns a specific function (authentication, payment processing, inventory). Composable architecture decomposes along business capabilities — each Packaged Business Capability (PBC) owns a complete business domain including its data, logic, APIs, and events.

The practical difference: a microservices migration often creates dozens of technical services that require the same coordination and deployment coupling as the original monolith. A composable architecture migration creates business-aligned units that can be sourced from different vendors, replaced independently, and governed by different teams.

Gartner's 2020 formulation defines three principles:

• Modularity — capabilities are independently deployable and encapsulated
• Autonomy — each capability manages its own lifecycle without coordinating releases with others
• Orchestration — a coordination layer connects capabilities into business processes without embedding business logic in the integration layer itself

MACH Principles in Practice

The MACH Alliance codified composable architecture's technical requirements as four principles. Understanding each principle reveals what it demands from your architecture.

Microservices

Each business function is a separately deployed service with its own data store. The microservices requirement in MACH is about deployment independence, not service granularity. A "microservice" in the MACH context might contain significant business logic — the key property is that it deploys without coordinating with other services.

Practical implication: services must not share databases. Shared databases create hidden coupling — a schema change in the shared database requires coordinating every service that reads from it. Each MACH service owns its data model and exposes data only through its API.

API-First

Every capability exposes its functionality through a well-designed API before (or simultaneously with) its implementation. API-first is a design discipline, not just a technical requirement.

An API-first process: design the API contract (OpenAPI specification) and share it with consuming teams before writing implementation code. This allows frontend and backend teams to develop in parallel against the same contract. Changes to the API contract require a version bump and a coordination process.

API-first also means that internal integrations use the same APIs as external integrations. There are no "backdoor" database connections or internal-only function calls between services.

Cloud-Native

Cloud-native means designed to exploit cloud infrastructure: auto-scaling, managed services, immutable infrastructure, and containerization. The constraint here is that cloud-native systems must be stateless between requests and must externalize state (session, cache) to managed services.

Cloud-native does not mean "runs in a cloud". It means architectural choices (12-factor app principles, container packaging, infrastructure-as-code) that make the system portable and operable without manual server management.

Headless

Headless separates the presentation layer from the business logic layer. A headless system exposes all functionality through APIs with no assumption about how it will be rendered. The same APIs serve a web frontend, a mobile app, a point-of-sale terminal, and a voice interface.

The headless constraint becomes essential when you have multiple channels (web, mobile, IoT, third-party integrations) that need the same underlying business capabilities but with different presentation requirements.

Packaged Business Capabilities: The Unit of Composition

A PBC is the atomic unit of composable architecture. It differs from a microservice in scope:

	Microservice	Packaged Business Capability
Scope	Technical function	Business domain
Data	Often shared	Always owned
API	Internal, technical	Business-oriented, stable
Sourcing	Built in-house	Built or bought
Team alignment	Technical team	Business domain team

A "Payment Processing" PBC owns the complete payment domain: payment method storage, payment initiation, fraud detection, refunds, dispute management, and payment analytics. It exposes a business API (not a CRUD database API) and can be sourced from a vendor like Stripe or Adyen — the consuming system does not know or care which.

PBC Examples Across Domains

E-commerce PBCs: Product Information Management (catalog, attributes, pricing), Order Management System, Cart and Checkout, Fulfillment and Shipping, Returns and Refunds, Customer Account and Profile.

Platform business PBCs: Listing Management, Search and Discovery, Booking Engine, Reviews and Trust, Payment and Escrow, Messaging, Notifications.

Enterprise PBCs: Identity and Access Management, Contract Management, Billing and Revenue, Analytics and Reporting, Document Management.

Each of these maps to a vendor ecosystem with multiple PBC options. Identity and Access Management has Auth0, Okta, and Keycloak. Product Information Management has Akeneo, Pimcore, and Contentful. The composable architecture makes the vendor decision reversible — replacing Auth0 with Okta means updating the identity PBC interface, not rewriting consuming applications.

API Orchestration Layer

The orchestration layer is what makes composable architecture work. It coordinates requests across multiple PBCs, enforces business process logic, and exposes a unified API to consumers.

Without an orchestration layer, consumers call each PBC directly, accumulate PBC-specific knowledge, and break when PBC contracts change. With an orchestration layer, consumers interact with a stable business API that hides PBC implementation details.

Orchestration Layer Responsibilities

API Gateway — the single entry point for external requests. Handles authentication, rate limiting, request routing, and protocol translation. The API Gateway should not contain business logic — it routes, it does not decide.

Business Process Orchestration — coordinates multi-step processes across PBCs. An order placement process might: (1) check inventory via Product PBC, (2) initiate payment via Payment PBC, (3) create order record via Order PBC, (4) trigger fulfillment via Shipping PBC, (5) publish order event to Notification PBC. This sequence lives in the orchestration layer, not in any individual PBC.

Backend for Frontend (BFF) — a channel-specific API layer that aggregates and transforms PBC data for a specific consumer. A mobile BFF returns lightweight payloads optimized for mobile bandwidth. A web BFF returns full page data. A voice BFF returns structured data for speech synthesis. BFFs eliminate the "over-fetching" problem (clients receiving data they do not need) and the "under-fetching" problem (clients making multiple round trips to assemble a single view).

Event Bus — asynchronous communication between PBCs. When Order PBC creates an order, it publishes an order.created event. Notification PBC, Analytics PBC, and Loyalty PBC each subscribe to this event and handle it independently. Event-driven coordination avoids synchronous coupling between PBCs.

Orchestration Anti-Patterns

Smart orchestration — putting business logic in the orchestration layer that belongs in a PBC. If your orchestration layer contains pricing rules, discount calculations, or inventory logic, you have built a new monolith inside your orchestration layer.

Chatty orchestration — orchestration processes that make dozens of synchronous API calls to compose a response. Aggregate data in the BFF layer using parallel calls and caching, not sequential calls.

Bypassing orchestration — allowing consumers to call PBCs directly "for performance". This creates hidden dependencies that break when PBC contracts change.

Composable Commerce Architecture

E-commerce is where composable architecture has the clearest business case. Monolithic commerce platforms (Magento, Salesforce Commerce Cloud, SAP Commerce) create vendor lock-in that limits the pace of product development. A composable commerce stack replaces the monolith with best-of-breed PBCs connected through an orchestration layer.

A reference composable commerce stack:

Business capability	Example vendors
Product Information Management	Akeneo, Pimcore
Search and Discovery	Algolia, Constructor
Cart and Checkout	Commercetools, custom
Payment Processing	Stripe, Adyen
Order Management	Fluent Commerce, custom
Content Management	Contentful, Sanity
Customer Data Platform	Segment, custom
Personalization	Dynamic Yield, Algolia
Frontend	Next.js, Nuxt.js

The orchestration layer (typically GraphQL or REST API gateway + BFF) connects these components into a coherent shopping experience.

When composable commerce makes sense: organizations processing more than $50M in GMV annually, where development velocity on the commerce platform is a competitive constraint. Below that threshold, the integration complexity and vendor management overhead may exceed the benefits of flexibility.

When it does not make sense: small teams, early-stage products, or businesses where commerce is not a core differentiator. A Shopify monolith with custom apps is often the right choice up to $50M GMV.

Best-of-Breed Selection Criteria

Best-of-breed selection is more complex than picking the highest-rated vendor in each category. Evaluation framework:

API quality — is the API well-documented, stable, and version-managed? Does it expose events for integration? Is there a sandbox environment? Does the vendor provide client libraries for your target languages?

Data ownership and portability — can you export your data in standard formats? What happens to your data if you terminate the contract? Vendors that lock data behind proprietary exports create vendor lock-in at the data layer even if you can swap the application.

Event and webhook support — composable architecture requires PBCs to emit events when state changes. A vendor that does not support webhooks or events forces synchronous polling, which degrades real-time integration.

Rate limits and SLA — a PBC that becomes unavailable takes down every process that depends on it. Evaluate SLA, rate limits, and the vendor's incident history. Circuit breaker patterns can limit blast radius, but availability SLAs must be acceptable.

Total cost — vendor per-transaction pricing compounds as volume grows. Model the cost at 2x and 10x current volume before selecting a vendor. Some "best-of-breed" vendors are only competitive at startup scale.

Migration Strategy: Monolith to Composable

Migrating a live system to composable architecture requires the strangler fig pattern — new capabilities are built composably around the existing monolith, and traffic is migrated gradually until the monolith can be decommissioned.

Phase 1: Identify PBC Candidates

Not everything should be migrated to composable architecture simultaneously. Start with capabilities that meet these criteria:

• High velocity of change (requiring frequent updates)
• Clear business domain boundaries
• Available vendor alternatives (if buy is preferred over build)
• Low risk of data migration complexity

Candidates that typically migrate first: authentication (replace custom auth with Auth0/Okta), search (replace custom search with Algolia), content management (replace embedded CMS with headless CMS).

Phase 2: Add the Orchestration Layer

Before extracting any PBC, add an API Gateway and orchestration layer in front of the monolith. This creates the routing infrastructure needed to direct traffic to new PBCs as they come online.

The monolith initially sits behind the orchestration layer unchanged. Consumers call the orchestration layer; it proxies to the monolith. This step has no functional impact on the running system.

Phase 3: Extract and Migrate

Extract one PBC at a time. For each extraction:

1. Build the new PBC (or configure the vendor)
2. Update the orchestration layer to route the relevant API calls to the new PBC
3. Migrate data from the monolith to the PBC's own data store
4. Validate with a canary traffic split (5% → 25% → 100%)
5. Remove the extracted capability from the monolith

Data migration is the riskiest step. For most PBCs, a dual-write period (write to both monolith and new PBC, read from monolith, gradually shift reads to new PBC) allows validation before full cutover.

Phase 4: Governance and API Management

As the number of PBCs grows, API management becomes critical:

• API versioning policy — how long are old API versions supported? Who is responsible for migration?
• Event schema registry — Confluent Schema Registry or similar for managing event contracts
• Developer portal — centralized documentation for all PBC APIs
• Observability — distributed tracing across the orchestration layer and PBCs

Without governance, composable architecture devolves into point-to-point integration chaos — the same problem it was meant to solve, in a different form.

Common Failure Patterns

Migration stall — organizations extract 2-3 PBCs and stop because the incremental cost of each migration exceeds the perceived benefit. Solution: front-load the highest-value migrations (identity, search, payments) to demonstrate ROI before attempting lower-value extractions.

Orchestration as monolith — the orchestration layer accumulates business logic until it becomes as difficult to change as the original monolith. Solution: enforce a strict rule that the orchestration layer handles routing, aggregation, and protocol translation only — no business logic.

Vendor sprawl — composable architecture can easily accumulate 20+ vendor relationships, each with its own pricing, SLA, support contract, and API to maintain. Solution: evaluate total vendor management cost before adopting each new PBC vendor; prefer fewer vendors with broader capability sets when flexibility requirements are not high.

Premature composability — applying composable architecture to a system that is not yet large enough to benefit from it. Solution: composable architecture is justified when team coordination costs exceed integration complexity costs, typically at 5+ team / 10+ engineers working on the same product surface.

Architecture Decision Framework

Choose composable architecture when:

• Multiple independent teams need to work on overlapping product surfaces
• The pace of change in specific business capabilities constrains the whole system
• Best-of-breed vendors exist for capabilities you do not want to build
• The organization has the engineering maturity to manage distributed systems

Do not choose composable architecture when:

• Single team, single product, early stage
• The integration complexity would exceed the flexibility benefits at current scale
• The organization lacks distributed systems experience
• Budget does not support the vendor ecosystem and engineering overhead

Composable architecture is not an end state — it is a spectrum. Most organizations benefit from extracting 3-5 high-value PBCs from an otherwise monolithic system before attempting a full composable transformation.