Introduction

In recent years, the MACH principles—Microservices, API-first, Cloud-native, and Headless—has been touted as the future of composable, agile digital platforms. Advocates of MACH argue that it allows organizations to innovate quickly by decoupling core systems and exposing functionality through APIs. However, as appealing as this modular approach is, it doesn’t introduce fundamentally new principles. In fact, it builds on ideas that have been around for decades, particularly from Service-Oriented Architecture (SOA). See also The Four Tenets of SOA.

Yet, the biggest challenge lies not in the principles or technologies themselves but in the complexity of integration. While MACH tends to gloss over integration issues by positioning APIs as the ultimate solution, the reality is much more nuanced—especially when viewed through the lens of Pace Layered Architecture.

MACH vs. SOA: New Technology, Old Principles

MACH principles are often positioned as cutting-edge compared to older architectures like SOA. However, if we break it down:

• Microservices in MACH are essentially an extension of SOA’s focus on service decomposition.
• API-first continues SOA’s emphasis on loose coupling through well-defined interfaces.
• Cloud-native leverages modern cloud infrastructure, but the idea of distributed systems was central to SOA.
• Headless separates the front-end from the back-end, much like SOA’s separation of presentation and business layers.

In essence, MACH doesn’t introduce new architectural principles but rather modernizes existing ones with updated technology stacks and operational patterns.

The Forgotten Challenge: Integration

While MACH focuses on modularity, flexibility, and speed, it tends to oversimplify the complexities of integration. Simply saying “APIs solve everything” is reductive. APIs are indeed critical, but the actual process of integrating systems—especially in complex, distributed environments—requires addressing far more nuanced challenges. Integration is not a one-size-fits-all solution; it involves handling synchronous, asynchronous, and event-driven communication depending on the use case.

For example:

• Synchronous vs. Asynchronous: Synchronous APIs may introduce latency or timeout issues, while asynchronous patterns require careful coordination to ensure data consistency across systems.
• Event-Driven Architectures: While event-driven patterns can reduce complexity at certain levels, they also introduce new challenges, like handling event sequencing and guaranteeing delivery in distributed systems.

For even more complexity watch “I Made Everything Loosely Coupled. Does My App Fall Apart?” by Gregor Hohpe.

Pace Layered Architecture: A Critical Lens

One of the most valuable ways to understand the complexity of integration is through the Pace Layered Architecture model. This model divides systems based on their rate of change:

• Systems of Record: These foundational systems (like ERP and finance) change slowly and are stable. Integration at this layer is generally easier because the interfaces are well-defined and don’t change often.
• Systems of Differentiation: These systems allow for more customization and differentiation, such as customer loyalty programs or product catalogs, and change moderately.
• Systems of Innovation: Fast-moving, innovation-driven systems, such as user interfaces or headless CMS, evolve rapidly.

If we look at the MACH principles through the lens of a Pace Layered Architecture, then the further down the stack, the slower the systems change and the easier the integration becomes. Conversely, at the top of the stack—where MACH promises speed and flexibility—the challenge of integrating diverse systems and managing rapid change becomes significantly harder.

The Reality of Integration Complexity

As the Pace Layered Architecture model shows, systems lower in the stack (such as ERP or finance) are easier to integrate because they change less often. However, the MACH promise of speed, especially in the higher layers (front-end, APIs), requires solving difficult integration problems. 

In the real world, APIs alone don’t automatically resolve the complexities of integrating systems across different domains and layers. You need to account for:

• Latency and data consistency: Ensuring real-time data syncs across systems that update at different speeds.
• Governance and ownership: Defining who controls the data and how changes are propagated across services.
• Error handling and recovery: Building resilience into systems so that failures in one service don’t cascade into others.

Conclusion

MACH architecture brings modern technology to the table, but it doesn’t fundamentally change the underlying principles of service orientation or integration. While APIs are a key enabler of composable systems, they don’t eliminate the complexities of integration—especially in a world where synchronous, asynchronous, and event-driven patterns coexist. 

Understanding these challenges through the lens of Pace Layered Architecture helps us see that the deeper we go into the stack, the easier integration becomes. But achieving the speed and flexibility that MACH promises at the higher layers requires solving some of the hardest integration problems in modern software architecture.

This page is an example standard which explains how all systems in Software Engineering in Digital Products in Carlsberg must use event driven architectures.

For context please see: Software Architecture Patterns

This means that each system or service that masters data (Order Service, Customer Service etc.) must raise (create, produce, publish, etc) an appropriate event to the central event hub using a specific topic every time a pre-defined action (business or just plain CRUD) occurs on data in that system or service. Systems or services which listens to these events (consumers, subscribers etc) can then based on meta data in the event decide if it’s required to go to the system or service API and get the full data which is associated with the event.

This means that every system or service which we build must support the following architecture pattern:

This is the order of events:

• The client performs an action through the API on Service A
• The change of state on the data in the Service causes the Service to raise an event on the central event hub on a specific topic B
• The event hub notifies all the consumers that an event on topic B has occurred
• The consumer examines the event and decides if it’s required to call the producers API to get the entire data of the event
• The consumer call the producers API with a direct link to get the entire data of the event (ideally using a unique identifier so that the data can be found in the in storage layer without having to search for it)

Introduction

This is an attempt at trying to create some highlevel patterns for Artificial Intelligence (AI) solutions in order to be able to more easily choose a pattern based on type and problem area.

The goal is to have something like Software Architecture Patterns which again is based on Useful resources on Software & Systems Architecture so that we quickly can choose how to solve problems with AI. This page is also a companion to Four and not 3 Categories of AI Solutions as the patterns on this page is meant for AI-Brewers.

Emerging Types of AI Solution Patterns

• Chatbots with LLMs: Automate interactions and provide instant, contextually relevant responses, enhancing customer service, information retrieval, and user engagement across various domains like e-commerce and healthcare.
• Chaining LLMs: Link multiple LLMs in sequence, leveraging their specialized capabilities for more nuanced and accurate solutions, enabling sophisticated workflows where each model performs tasks it excels at.
• State machines and directed graphs: This approach introduces cycles, meaning the system can loop back and reconsider previous steps, which allows for more complex decision-making and adaptive behaviors. The state machine can maintain a state based on previous interactions, which can influence future decisions and actions.
• Orchestrating LLMs: Simplify the integration and management of multiple LLMs to work in harmony, improving the development, performance, and scalability of AI-driven applications by leveraging the strengths of diverse models.

Would be a neglect not to mention RAG here although more of a feature than a solution pattern:

• Retrieval Augmentation Generation (RAG): RAG combines the power of LLMs with a retrieval mechanism to enhance response accuracy and relevance. By fetching information from a database or collection of documents before generating a response, RAG models can provide answers that are more detailed and contextually appropriate, drawing from a wide range of sources. This approach significantly improves performance on tasks requiring specific knowledge or factual information, making RAG models particularly useful for applications like question answering and content creation.

Graphs and orchestration is also commonly referred to as “Agentic” architectures.

Chatbots with LLMs

Bots and chat-based interfaces powered by Large Language Models (LLMs) address a wide array of problem areas by automating interactions and processing natural language inputs to provide instant, contextually relevant responses.

These AI-driven solutions revolutionize customer service, information retrieval, and interactive experiences by enabling scalable, 24/7 availability without the need for human intervention in every instance.

They excel in understanding and generating human-like text, making them ideal for answering queries, offering recommendations, facilitating transactions, and supporting users in navigating complex information landscapes.

Furthermore, they significantly enhance user engagement by providing personalized interactions, thereby improving satisfaction and efficiency in areas such as e-commerce, education, healthcare, and beyond. By harnessing the capabilities of LLMs, bots and chat interfaces can decode intricate user intents, engage in meaningful dialogues, and automate tasks that traditionally required human intelligence, thus solving key challenges in accessibility, scalability, and automation in digital services.

Chaining LLMs

Chaining LLMs involves linking multiple LLMs in sequence to process information or solve problems in a stepwise manner, where the output of one model becomes the input for the next. This technique utilizes the specialized capabilities of different LLMs to achieve more complex, nuanced, and accurate solutions than could be provided by any single LLM.

Through this approach, developers can create advanced workflows in which each model is tasked with a specific function it excels at, ranging from understanding context to generating content or refining answers. This method significantly enhances the effectiveness and efficiency of AI systems, allowing them to address a wider variety of tasks with greater precision and contextual relevance. Chaining LLMs thus represents a strategic approach to leveraging the complementary strengths of various models, paving the way for more intelligent, adaptable, and capable AI-driven solutions.

Chaining LLMs is particularly effective for solving problems that benefit from a multi-step approach, where each step might require a different kind of processing or expertise. Here are some examples of problems typically solved using chaining:

• Complex Query Resolution: Simplifying and addressing multifaceted queries through a stepwise refinement process.
• Content Creation and Refinement: Generating drafts and then improving them through editing, summarization, or styling in successive steps.
• Decision Support Systems: Deriving insights and suggesting actions through a sequential analysis and decision-making process.
• Educational Tutoring and Adaptive Learning: Providing personalized educational feedback and instruction based on initial assessments.

These examples highlight the versatility of chaining LLMs, enabling solutions that are not only more sophisticated and tailored but also capable of handling tasks that require depth, precision, and a layered understanding of context.

Directed Graphs

State machines (a directed graph) are abstract machines that can be in exactly one of a finite number of states at any given time. In the context of LLMs and LangChain, a state machine would manage the flow of interactions with the LLM, keeping track of the context and state of conversations or processes.

• LangGraph is designed to facilitate the creation, expansion, and querying of knowledge graphs using language models. It uniquely combines the representational power of knowledge graphs—structures that encode information in a graph format where nodes represent entities and edges represent relationships between entities—with the generative and understanding capabilities of language models. This integration allows for sophisticated semantic reasoning, enabling applications to derive insights and answers from a rich, interconnected dataset.
• The primary value of LangGraph lies in its ability to leverage the contextual awareness and depth of language models to enrich knowledge graphs. This makes it particularly well-suited for applications requiring complex query answering, semantic search, and dynamic knowledge base expansion. It’s about not just processing language but understanding and organizing information in a way that mirrors human cognition.

Orchestrating LLMs

A framework for orchestrating LLMs is aimed at tackling the intricate challenges of integrating and managing multiple LLMs to work in harmony. Such a framework simplifies the process of combining the capabilities of diverse LLMs, enabling developers to construct more complex and efficient AI-driven solutions. It offers tools and methodologies for seamless integration, enhancing the development process, and allowing for the creation of applications that leverage the strengths of various LLMs. This not only streamlines the development of sophisticated applications but also boosts their performance and scalability, facilitating the customization of AI solutions to meet specific needs and contexts.

Orchestrating LLMs involves coordinating multiple models to work together efficiently, often in parallel or in a dynamic sequence, to tackle complex tasks. This approach is particularly useful for problems that benefit from the combined capabilities of different LLMs, each bringing its unique strength to the solution. Here are some examples of problems typically solved using orchestration:

• Multi-domain Knowledge Integration: Coordinating specialized LLMs to offer solutions that require expertise across various fields.
• Personalized User Experiences: Dynamically combining LLM outputs to customize interactions according to user data.
• Complex Workflow Automation: Utilizing different LLMs for distinct tasks within a broader workflow, optimizing for efficiency and effectiveness.
• Advanced Customer Support Systems: Integrating various LLMs to understand, process, and respond to customer inquiries in a nuanced and effective manner.

Orchestration enables the leveraging of multiple LLMs’ strengths in a coordinated manner, offering solutions that are more versatile, scalable, and capable of addressing the multifaceted nature of real-world problems.

Introduction

The following is an subset of software architecture patterns, which tend to be referenced when academic discussions around patterns arise. The following are my comments.

Patterns

Application Architecture

Microservice

The microservice pattern comes from domain-driven design where in particular the concept of bounded context came to be the decoupling of services. The post Microservices by Martin Fowler also played a large part in naming this pattern.

Drivers:

• Loosely coupled with other services – enables a team to work independently the majority of time on their service(s) without being impacted by changes to other services and without affecting other services
• Independently deployable – enables a team to deploy their service without having to coordinate with other teams
• Capable of being developed by a small team – essential for high productivity by avoiding the high communication head of large teams
• The application must be easy to understand and modify
• You must run multiple instances of the application on multiple machines in order to satisfy scalability and availability requirements
• You want to take advantage of emerging technologies (frameworks, programming languages, etc)

Problems:

• Managing dependencies
• Deployments of the entire system may become complex
• Developers must implement the inter-service communication mechanism and deal with partial failure
• Implementing requests that span multiple services is more difficult
• Testing the interactions between services is more difficult
• Implementing requests that span multiple services requires careful coordination between the teams

Database

Database per Service

This pattern is basically the natural follow-on to choosing the microservice application architecture pattern, where if a service is to become independant, then it must have it’s own independant data layer.

Drivers:

• Services must be loosely coupled so that they can be developed, deployed and scaled independently
• Databases must sometimes be replicated in order to scale
• Different services have different data storage requirements, like relational database or NoSQL

Problems:

• How to manage consistency across services
• Who owns (masters) data?

Messaging

Messaging is a communications pattern which uses asynchronous messaging to replace the synchronous style of request/response used in most REST-style APIs. Most common styles of asynchronous messaging are:

• Notifications – a sender sends a message a recipient but does not expect a reply. Nor is one sent.
• Request/asynchronous response – a service sends a request message to a recipient and expects to receive a reply message eventually
• Publish/subscribe – a service publishes a message to zero or more recipients
• Publish/asynchronous response – a service publishes a request to one or recipients, some of whom send back a reply

In the following there’s no differentiation between “event”-driven and “data”-driven, as a message will always contain the full message body.

Event Driven with full Messages

Drivers:

• The complete body of the message must be sent in each event
• The broker may or may not allow for queries against the messages
• Extreme loose coupling as the sender is completely decoupled from the receiver

Problems:

• Subscriber/consumer overload which requires buffering so that events are not lost
• The broker/mediator must always be available
• Almost always creates mixed messaging styles with events for downstream and request/response across and upstream which requires carefull planning

Broker

Event driven messaging with a broker implies that all messages are delivered through a central broker but that there’s no processing control flow and messages are delivered using a publish/subscribe pattern.

Drivers:

• Scalability

Problems:

• How to handle orchestration? With “normal” synchronous request/response messaging services orchestrate business processes in the order that they are called – with broker driven messaging everybody potentially could get the same message at the same time, so who orchestrates the overall process?

Mediater

A mediater expands on the broker with support for business process workflows usually with support for BPEL.

Drivers:

• Business processes change often
• Traceability and governance is important

Problems:

• Management and governance of platform takes time
• Requires turnkey solutions from major vendors
• Not really available as a cloud solution

Event Driven with Notifications

Drivers:

• You don’t know how many subscribers/consumers of your events there will be, so you must preserve bandwidth
• The size of the payload in the event is limited
• A subset of the events doesn’t require the complete body of the message to be sent
• Subscribers explicitly want to chose which message bodies they want to pull

Problems:

• Requires a two-step dance where the consumer of an event must issue a request to the central broker and ask for the full body of the message