One System, Many Possibilities - Exploring Monoliths, Events, and LLMs

Monolithic systems can be great for small-scale or early-stage projects. They’re straightforward to build from the ground up, often scale adequately with initial needs, and benefit from a wealth of established solutions. In today’s fast-moving digital world, businesses rely on software to stay competitive, deliver great customer experiences, and adapt to change. However, as systems grow, many organizations find themselves held back by these same monolithic architectures, which become large, complex, and difficult to update. For many different reasons, monolithic systems lead to these issues. Monolithic systems, where all functions are packed into a single codebase, create bottlenecks that slow innovation and frustrate teams. As someone who’s worked with these challenges, I’ve seen firsthand how they can stifle progress, and I’ve come to believe that modern approaches like microservices and event-driven architectures (EDA) are the way forward. This article, inspired by an insightful article (https://seanfalconer.medium.com/why-googles-agent2agent-protocol-needs-apache-kafka-507b1ec456a6) shared by my friend Mike Bird, examines the limitations of monolithic systems, the advantages of microservices, and the transformative potential of event-driven architectures. We’ll also explore their relevance to artificial intelligence (AI), particularly through Google’s Agent2Agent (A2A) protocol, an open standard that enables secure, interoperable communication between AI agents using HTTP and JSON-RPC. The Problem with Monolithic Systems Monolithic systems are like giant, all-in-one machines where every part—user interface, business logic, and data access—is tightly woven together. This setup, known as monolithic architecture, was once the standard in software development because it’s straightforward to build and deploy initially. However, as systems grow, their complexity becomes problematic. There are a few challenges to it: Slow Updates: Even a tiny change, like fixing a button on a website, requires rebundling and redeploying the entire application. This process is time-consuming and prone to errors, delaying new features or bug fixes. Tangled Code: Monoliths often lead to “spaghetti code,” where dependencies between components are so intertwined that modifying one part risks breaking others. This makes maintenance a nightmare. Scaling Issues: If one function, like payment processing, gets heavy traffic, the whole system must be scaled up, wasting resources on less busy parts. Innovation Struggles: Businesses struggle to integrate new technologies or respond to market changes because the system is rigid and hard to adapt. For example, imagine a retail company using a monolithic e-commerce platform. Adding a new payment method, like cryptocurrency, could take months because the payment module is tightly coupled with inventory management, user authentication, and checkout processes. Developers must update the entire codebase, test every interconnected feature, and redeploy the whole system—delaying the rollout and potentially losing customers to competitors with faster, more modular platforms. I’ve felt this frustration myself when working with large systems that resist change. It’s like trying to renovate a house where moving one wall risks collapsing the entire structure. Businesses today can’t afford this kind of inflexibility—they need software that evolves as quickly as their markets do. Bringing this concept to A2A The limitations of monolithic systems, such as slow updates, tangled code, and scaling inefficiencies, mirror some of the challenges faced by Google’s Agent2Agent (A2A) protocol in its current form. A2A, designed for interoperable communication using HTTP and JSON-RPC, operates in a request-response model that can become a bottleneck in large-scale dynamic AI ecosystems. This synchronous, request-response approach mirrors the tightly coupled nature of monoliths, where components depend heavily on direct interactions. In A2A, each AI agent must wait for a response from another before proceeding, which causes difficulty to its ability to handle the high-volume, asynchronous interactions needed for real-time collaboration in large-scale AI ecosystems. As an example, in a smart city application, agents managing traffic, weather, and energy data might need to coordinate instantly. The sequential nature of HTTP calls creates delays, much like a monolithic system bogged down by a single change, making maintenance and scaling increasingly complex. In contrast, an event-driven architecture, such as one leveraging a message bus like Apache Kafka, could address these scalability issues by enabling asynchronous, decoupled communication. Kafka’s event-streaming capabilities allow systems to publish and subscribe to events in real time, distributing workloads efficiently across components, similar to how microservices break down monolithic systems into manageable, independent unit

May 12, 2025 - 01:40

One System, Many Possibilities - Exploring Monoliths, Events, and LLMs

Monolithic systems can be great for small-scale or early-stage projects. They’re straightforward to build from the ground up, often scale adequately with initial needs, and benefit from a wealth of established solutions. In today’s fast-moving digital world, businesses rely on software to stay competitive, deliver great customer experiences, and adapt to change. However, as systems grow, many organizations find themselves held back by these same monolithic architectures, which become large, complex, and difficult to update. For many different reasons, monolithic systems lead to these issues. Monolithic systems, where all functions are packed into a single codebase, create bottlenecks that slow innovation and frustrate teams. As someone who’s worked with these challenges, I’ve seen firsthand how they can stifle progress, and I’ve come to believe that modern approaches like microservices and event-driven architectures (EDA) are the way forward.

This article, inspired by an insightful article (https://seanfalconer.medium.com/why-googles-agent2agent-protocol-needs-apache-kafka-507b1ec456a6) shared by my friend Mike Bird, examines the limitations of monolithic systems, the advantages of microservices, and the transformative potential of event-driven architectures. We’ll also explore their relevance to artificial intelligence (AI), particularly through Google’s Agent2Agent (A2A) protocol, an open standard that enables secure, interoperable communication between AI agents using HTTP and JSON-RPC.

The Problem with Monolithic Systems

Monolithic systems are like giant, all-in-one machines where every part—user interface, business logic, and data access—is tightly woven together. This setup, known as monolithic architecture, was once the standard in software development because it’s straightforward to build and deploy initially. However, as systems grow, their complexity becomes problematic. There are a few challenges to it:

Slow Updates: Even a tiny change, like fixing a button on a website, requires rebundling and redeploying the entire application. This process is time-consuming and prone to errors, delaying new features or bug fixes.
Tangled Code: Monoliths often lead to “spaghetti code,” where dependencies between components are so intertwined that modifying one part risks breaking others. This makes maintenance a nightmare.
Scaling Issues: If one function, like payment processing, gets heavy traffic, the whole system must be scaled up, wasting resources on less busy parts.
Innovation Struggles: Businesses struggle to integrate new technologies or respond to market changes because the system is rigid and hard to adapt.

For example, imagine a retail company using a monolithic e-commerce platform. Adding a new payment method, like cryptocurrency, could take months because the payment module is tightly coupled with inventory management, user authentication, and checkout processes. Developers must update the entire codebase, test every interconnected feature, and redeploy the whole system—delaying the rollout and potentially losing customers to competitors with faster, more modular platforms.

I’ve felt this frustration myself when working with large systems that resist change. It’s like trying to renovate a house where moving one wall risks collapsing the entire structure. Businesses today can’t afford this kind of inflexibility—they need software that evolves as quickly as their markets do.

Bringing this concept to A2A

The limitations of monolithic systems, such as slow updates, tangled code, and scaling inefficiencies, mirror some of the challenges faced by Google’s Agent2Agent (A2A) protocol in its current form. A2A, designed for interoperable communication using HTTP and JSON-RPC, operates in a request-response model that can become a bottleneck in large-scale dynamic AI ecosystems. This synchronous, request-response approach mirrors the tightly coupled nature of monoliths, where components depend heavily on direct interactions. In A2A, each AI agent must wait for a response from another before proceeding, which causes difficulty to its ability to handle the high-volume, asynchronous interactions needed for real-time collaboration in large-scale AI ecosystems. As an example, in a smart city application, agents managing traffic, weather, and energy data might need to coordinate instantly. The sequential nature of HTTP calls creates delays, much like a monolithic system bogged down by a single change, making maintenance and scaling increasingly complex.

In contrast, an event-driven architecture, such as one leveraging a message bus like Apache Kafka, could address these scalability issues by enabling asynchronous, decoupled communication. Kafka’s event-streaming capabilities allow systems to publish and subscribe to events in real time, distributing workloads efficiently across components, similar to how microservices break down monolithic systems into manageable, independent units. If A2A were to adopt an event-oriented approach, AI agents could publish tasks or data to a Kafka topic, allowing other agents to consume and process them at their own pace, reducing bottlenecks and improving scalability. This is where Sean Falconer's article shines: this shift would make A2A more adaptable to the demands of modern AI systems, just as businesses transitioning from monoliths to microservices would gain the agility to innovate and respond to market changes swiftly. I intentionally used the word "would," as software investments are not always successful, and I wanted to emphasize the inherent risks.

My Experience with Microservices

I’ve long been a fan of microservices. In my work, I’ve experimented with ready-made systems, focusing on their interfaces rather than their internals, to adapt them for advanced business needs. For example, I once worked on integrating multiple digital asset processing services into a business workflow by building an interface that translated their inputs and outputs into the client’s format. Any problem with the integration would have to be dealt internally in the microservice implementation. This black-box approach simplified the process, letting me focus on delivering business value without getting bogged down in the system’s complexity.

However, I learned that ignoring the underlying system entirely can backfire. In one project, performance issues arose because I didn’t account for how the microservice dependency on external integrations would affect the higher level functionalities. This taught me that while microservices and black-box thinking are powerful, understanding key internals is sometimes necessary - in this case, knowing the potential ways that it could fail, and its consequences were key to solve the problem.

This experience connects to AI, particularly large language models (LLMs), which are often treated as black boxes. We use their inputs and outputs without fully understanding their inner workings. But as I found, we can’t always ignore the “sausages being made” if we want reliable functionality.

Event-Driven Architectures: Decoupling for Scalability

Event-driven architectures (EDA) take decoupling to the next level. In EDA, services communicate by producing and consuming events—messages that signal something has happened, like a customer placing an order or a sensor detecting a change.

Its setup is asynchronous, meaning producers don’t wait for consumers to respond, and consumers don’t need to know whom to send the event. This loose coupling enhances flexibility and scalability.

Benefits:

Loose Coupling: Services only need to know about events, not each other, making it easy to add or remove services without disrupting the system.
Scalability: Events can be processed in parallel, handling high traffic efficiently. For example, during a Black Friday sale, an e-commerce system can process thousands of order events simultaneously.
Real-Time Responsiveness: Systems react to events as they happen, enabling instant updates, like notifying a customer when their order ships.
Simplified Infrastructure: As I’ve noted, EDA moves infrastructure logic (like coordinating services) out of the software layer, reducing complexity in the codebase.

Real-World Examples

EDA is used across industries to solve real-world problems:

Heineken: Connects over 4,500 internal applications using EDA, streamlining payments, logistics, and inventory management across legacy systems.
Federal Aviation Administration: Uses EDA to share real-time air traffic data with airlines, ensuring timely updates without constant polling.
E-commerce: Companies like Amazon use EDA for real-time inventory updates, reducing stockouts and improving customer trust. > Source: https://solace.com/what-is-event-driven-architecture/

These examples show how EDA enables businesses to respond quickly to changes, a critical advantage in competitive markets.

Applying Event-Driven Architectures to AI Systems

Event-driven architectures (EDA) offer significant benefits for AI systems, enabling real-time processing of vast datasets and seamless coordination among components. Google’s Agent2Agent (A2A) protocol exemplifies this potential by facilitating standardized communication between AI agents from different vendors, though it currently faces scalability challenges due to its reliance on HTTP and JSON-RPC rather than an event-streaming platform like Apache Kafka - as mentioned in Falconer's article.

Its point-to-point communication model, where agents connect directly, struggles with enterprise-scale complexity:

Too Many Connections: As agent numbers increase, direct connections create a complex web of dependencies.
Tight Coupling: Agents depend on each other’s availability, limiting flexibility.
Limited Visibility: Monitoring interactions across agents is difficult, hindering debugging and auditing.

This is where I agree with Falconer: integrating an event-streaming platform like Apache Kafka could enhance A2A’s scalability and efficiency. Just to mention, here are a few reasons:

Decoupled Communication: Agents publish events to Kafka topics, and others subscribe to relevant events, eliminating direct dependencies.
Scalability: Kafka efficiently manages high event volumes, supporting large-scale AI ecosystems.
Real-Time Orchestration: Events are processed instantly, enabling dynamic collaboration, such as multiple agents updating a customer profile simultaneously.
Observability: Kafka’s event logs simplify monitoring and auditing of agent interactions.

For example, in a customer service AI ecosystem, a chatbot agent could publish a customer query to a Kafka topic. A data analytics agent might subscribe to analyze sentiment, while a CRM agent updates the customer’s profile. This seamless interaction occurs without agents needing direct knowledge of each other, leveraging Kafka’s event-driven framework.

EDA and LLMs

EDA’s principles also enhance large language models (LLMs) and AI services. LLMs, often complex and opaque, benefit from event-driven triggers, such as user feedback or new data, to update models incrementally without system-wide overhauls. For instance, a content creation AI could respond to an event signaling a new user-submitted topic, generating relevant material in real time. This approach mirrors microservices’ incremental evolution, ensuring AI systems remain responsive and adaptable as they integrate into business processes.

I hope this inspires insightful considerations, just as Falconer’s article inspired me. Thanks Mike!