DEV Community: Savio Resende

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

Savio Resende — Mon, 12 May 2025 00:15:05 +0000

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!

Implementing Atomic Design Principles in Laravel

Savio Resende — Wed, 05 Mar 2025 19:20:09 +0000

Introduction

Atomic design is a methodology developed by Brad Frost that allows developers to construct UIs from individual parts, starting from basic building blocks. These components or parts, named after chemistry's basic building blocks, include atoms, molecules, organisms, templates, and pages. In this blog post, we'll review how to use these principles in a Laravel application.

The Origins of Atomic Design

The Atomic Design methodology was conceived by Brad Frost. The philosophy behind Atomic Design takes its inspiration from the world of chemistry. The idea is that all matter in the universe is made up of atoms, which combine to form molecules, which in turn combine to form more complex structures.

In 2013, Frost first wrote about Atomic Design in a blog post, introducing a new way to think about constructing web interfaces. His methodology encourages designers and developers to break down interfaces into fundamental building blocks (which he named "atoms") and then hierarchically combine these blocks to form more complex, reusable components (or "molecules" and "organisms"). This concept was expanded further in his book, also titled "Atomic Design", which was published in 2016.

Brad Frost's approach to design has resonated with many in web development for its logical, efficient, and maintainable way of constructing UIs. From a single atom to a complex interface, Atomic Design gives us a methodology for creating, testing and maintaining robust design systems. This makes it a natural fit for modern, component-based web frameworks like Laravel.

What is Atomic Design?

Atomic design, as said, involves creating interfaces deliberately and hierarchically. It breaks down UI into the following parts:

Atoms: These are the most basic building blocks. Examples include buttons, input fields, and other HTML elements.

Molecules: A group of atoms functioning together as a unit. Examples include a form element composed of label and input atoms.

Organisms: Complex UI components composed of groups of molecules and/or atoms and molecules. Examples include a header consisting of logo, navigation, and search form molecules.

Templates: Page-level objects that place components into a design and layout context. Templates lay out the design.

Pages: These are specific instances of templates. Here, placeholder content is replaced with real content.

Example: Building a Blog Comment System

Let's go through an example where we create a simple commenting system for a blog post. We'll start from atoms and build our way up to a complete page.

Atoms

The basic building blocks of your interface, like an input field:

<!-- resources/views/components/atoms/input.blade.php -->

<input {{ $attributes->merge(['class' => 'form-input']) }} />

Molecules

Molecules are groups of atoms functioning together. For example, a comment form molecule that uses the input atom:

<!-- resources/views/components/molecules/comment-form.blade.php -->

<form method="POST" action="/comment">
    @csrf
    <x-atoms.input type="text" name="username" placeholder="Enter your username" />
    <x-atoms.input type="text" name="comment" placeholder="Enter your comment" />
    <button type="submit">Submit</button>
</form>

Organisms

Organisms are groups of molecules joined together. In our example, a comments section that includes multiple instances of the comment form:

<!-- resources/views/components/organisms/comments-section.blade.php -->

<section>
    <h2>Comments</h2>
    <x-molecules.comment-form />
    @foreach($comments as $comment)
        <article>
            <h3>{{ $comment->username }}</h3>
            <p>{{ $comment->body }}</p>
        </article>
    @endforeach
</section>

Templates

Templates place components into a layout. For our blog, we can create a template for a blog post that includes the comment section:

<!-- resources/views/components/templates/blog-post.blade.php -->

<article>
    <h1>{{ $post->title }}</h1>
    <p>{{ $post->body }}</p>
</article>

<x-organisms.comments-section :comments="$post->comments" />

Pages

Finally, pages are instances of templates that show what a UI looks like with real representative content in place. A blog page that makes use of the blog post template would look like this:

<!-- resources/views/pages/blog.blade.php -->

@extends('layouts.app')

@section('content')
    @foreach($posts as $post)
        <x-templates.blog-post :post="$post" />
    @endforeach
@endsection

Conclusion

You can create reusable, maintainable, and organized code by structuring your Laravel components according to the atomic design methodology. This approach allows for a more efficient and scalable development process. When building your applications, always consider how you can break down your interfaces into these atomic components to make your work easier and your code cleaner.

Remember, building reusable components with a clear, well-defined purpose and interface is key to creating reusable components. It's also important to ensure they are well-documented and that they are easy to test and maintain. Happy coding!

Avoid This Laravel Enum Trap: Learn How to Fix It Before It Breaks Your Project!

Savio Resende — Sun, 02 Feb 2025 20:12:07 +0000

Enums are a way to represent a fixed set of values in your application, often tied to specific use cases like statuses, roles, or categories. Laravel allows developers to use type casting with enums to ensure these values are strictly typed when retrieved from the database, making the code cleaner and reducing potential bugs. However, while type casting might initially seem like an organized and efficient solution, it can lead to significant challenges as your software evolves and your codebase grows, especially in legacy systems.

In an ideal software development world, every new task starts fresh. You begin by creating a clean database and then you tailor it to the task at hand, ensuring that your initial dataset is perfectly seeded to reproduce specific scenarios. This allows you to write precise tests to validate those scenarios while covering additional cases as they happen. When new or unique scenarios are required, the process becomes iterative—you intentionally design and implement them with a clear focus.

This approach assumes you’re starting with greenfield projects or maintaining codebases with flawless processes. But in the real world, especially when maintaining legacy code, things aren’t so simple. As software evolves, enums and their use cases change. New cases are added, old cases become deprecated, and business requirements shift over time. Deprecating enum cases introduces complexity. When you deprecate a specific enum case, you might mark it as such in your code, intending to remove it in the future. But if that enum value is persisted in your database, removing it becomes problematic.

Here’s where things get tricky: (1) If you remove the deprecated case from your enum class but it still exists in your database, Laravel's magic type casting in Eloquent models will throw the error "X is not a valid backing value for enum EnumClassY." (2) Debugging becomes a nightmare. Since the error originates from Laravel’s magical type casting, it’s often difficult to trace its source, much like debugging errors in virtualized DOM frameworks in JavaScript. Without prior experience with this specific issue, you might struggle to find a solution.

This happens for 3 reasons:

First, Laravel’s Eloquent models simplify many tasks, but their magic can become a double-edged sword. When enum casting fails, you’re left without a clear stack trace or error source.
Second, even if you’ve deprecated a value in your code, that value may still exist in your database. Deleting data to resolve the issue is often not an option, especially when working with production environments where data integrity is critical. Suddenly, you might see an error that you can’t trace back to its source, and you’re left with a broken system.
Third, imagine deploying a version of your application where a new enum case has been added via a migration. If a bug forces you to roll back to an older version of your codebase that doesn’t yet recognize the new case, you’re in trouble. The old code won’t know how to handle the new enum, causing further errors.
After battling with these issues, here are 2 insights:

Avoid Over-reliance on Enum Casting: while it’s tempting to cast enums directly in your models, remember that doing so ties your database data too tightly to your code.
Making casting intentional by using a custom enum caster is ideal since it allows you to handle errors gracefully. Instead of letting uncaught exceptions occur when trying to use an enum that is deprecated or nonexistent, you can implement logic to report the issue clearly. This approach ensures the system fails in a controlled and debuggable manner, reducing confusion and enabling quicker resolution of problems.
Let’s consider a concrete example to understand how to handle enums in a way that avoids issues. Imagine you’re adding a type column to your users table. This column specifies the type of user, and at a certain point, your requirements define three types: bot, robot, and user. Over time, the requirements evolve: robot type is deprecated. Despite deprecation, some records in your database still reference the robot type, and some business logic relies on its existence. This includes contextual data, like model states, which were influenced by the robot type. Workflows and processes were built around the robot type, and removing it entirely could break your application.

Now, you face a decision: should you remove the robot value from the type column, or handle it differently? Simply deleting the value introduces risks, such as breaking existing business rules or losing historical context. However, leaving it indefinitely can lead to technical debt and confusion. The best approach is a middle ground, leveraging Laravel’s custom casters to handle these scenarios gracefully.

A custom caster allows you to customize how Eloquent models handle type casting, avoiding uncaught exceptions while giving you the flexibility to decide how to handle deprecated or invalid enum values (instead of having to handle with an exception every time you instantiate your users).

In the Listing 1 is my proposal Caster:

<?php  

namespace App\Casts;  

use App\Enums\UserType;  
use Illuminate\Contracts\Database\Eloquent\CastsAttributes;  
use Illuminate\Database\Eloquent\Model;  

class UserTypeCast implements CastsAttributes  
{  
    /**  
     * @param  array<string, mixed>  $attributes  
     */  
    public function get(Model $model, string $key, mixed $value, array $attributes): mixed  
    {  
        return rescue(fn() => UserType::tryFrom($value), report: false);  
    }  

    /**  
     * @param  array<string, mixed>  $attributes  
     */  
    public function set(Model $model, string $key, mixed $value, array $attributes): mixed  
    {  
        return $value instanceof UserType ? $value->value : $value;  
    }  
}

Listing 1: Custom Caster for UserType

Takeaways from this strategy:

Graceful Failure: Instead of throwing an uncaught exception, the custom caster logs and reports invalid enum values, enabling you to track issues.

Flexibility: Returning null allows you to decide at runtime how to handle deprecated or missing values without breaking the application.

Maintainability: This approach prevents the accumulation of technical debt by encouraging proactive handling of edge cases and legacy data.

User-side Decisions: By not breaking the application, you enable system users to decide how to handle deprecated values, such as converting to a default type or retiring the record.

Type casting for enums in Laravel can seem like an elegant solution at first glance. But as your application grows, what starts as a helpful feature can quickly turn into a maintenance burden. By understanding the pitfalls and planning for the future, you can avoid getting trapped by past decisions. Remember, experience often teaches us that simplicity and foresight are the keys to robust, maintainable software.