Search for a command to run...
I am a Journalist-turned-Software Engineer. I love coding and the associated grind of learning every day. A firm believer in social learning, I owe my dev career to all the tech content creators I have learned from. This is my contribution back to the community.
No comments yet. Be the first to comment.
What is it Microkernel architecture, also known as plug-in architecture, is a software design pattern that separates a system's core functionalities from non-core functionalities. In this pattern, the core functionality, also known as the microkernel...
📖 Introduction In modern AI applications, communication between clients and tools isn’t always as simple as calling an API. The Model Context Protocol (MCP) provides a standardized way for clients to exchange information, invoke tools, and maintain ...
If you’re curious about how to build an intelligent agent using Model Context Protocol (MCP), you’re in the right place. In this post, I’ll walk you through how to: Create an MCP Server using FastMCP Expose a tool that calculates BMI Build a Clien...
In our previous tutorial, we built a restaurant customer support chatbot using OpenAI's Agents SDK. In this follow-up, we’ll explore guardrails—a critical feature that enhances AI chatbot safety and reliability. What Are Guardrails in AI Agents? Guar...
Video https://www.youtube.com/watch?v=UPBMkFSJdBI The Problem at Hand Uber's data platform processes approximately 1.2 million interactive queries monthly, with 36% of these coming from the operations organization. This group—comprising engineers...
Video https://www.youtube.com/watch?v=FgRGwnpd2HY Google's recent white paper on "Agents" has created quite a buzz. The paper explores the concept of AI agents and delves into their architecture and potential. Let's break down what this white paper...
I am Zahiruddin Tavargere (Zahere). A social-learner, here to learn, share and grow with the tech community.
74 posts
I am Zahiruddin Tavargere (Zahere). A firm believer in social learning, I owe my dev career to all the tech content creators I have learned from - this is my contribution back to the community.
Imagine this: You've been tasked with converting a monolithic application into a more modern, scalable architecture.
You diligently decompose the monolith by features, creating a separate service for each one and deploying them to the cloud.
You're feeling pretty good about yourself - after all, you've just built a microservices architecture from scratch!
But as your application starts to scale, you begin to notice something odd. Every time you need to deploy a new feature, you find yourself having to deploy not just one service, but many.
And if something goes wrong with one of those services, it can have a ripple effect throughout the entire application.
That's when you realize you've engineered a 'Distributed Monolith'.
This mistake is actually quite common. It's so widespread that it even has a name: the "microservices trap."
You see, it's easy to think that breaking up your application into individual services is enough to create a microservices architecture. But in reality, true microservices architectures require much more than that.
In this article, we explore methods to avoid the transformation of intended microservices architecture into a distributed monolith.
The Distributed Monolith system may share some resemblances with the microservices architecture, but it maintains tight internal interconnectivity, much like a monolithic application.
In simple terms, it is an application that is deployed like a microservice but is built like a monolith.
You have built a distributed monolith if you are experiencing any one of the below...
In a distributed monolith architecture, implementation coupling refers to the tight coupling between the various services that make up the system.
This type of coupling occurs when two or more services are dependent on each other's implementation details, making it difficult to make changes to one service without affecting the others.
For example, if one service in a distributed monolith relies on the implementation details of another service, any changes made to the second service will affect the first service. This type of coupling can lead to cascading changes across the system and can make it difficult to maintain and scale the application.
Implementation coupling can be particularly problematic in a distributed monolith architecture because it can limit the ability to independently deploy and scale services.
One of the major challenges of a distributed monolith architecture is latency.
When services are tightly coupled and rely on synchronous communication between multiple services, it can significantly impact the application's throughput.
Synchronous communication can introduce high latency.
For instance, if Service A sends a request to Service B and it takes a long time to respond due to a crash or slow server, it can increase the overall latency of communication and affect the application's throughput.
This undermines the purpose of implementing a microservices architecture, which is to improve scalability and resilience by breaking down functionality into independent units.
In a distributed monolith, sharing a common database among services creates tight coupling and undermines the benefits of a microservices architecture.
When services share the same datastore, changes made by one service can have a ripple effect on other services that use the same datastore.
For instance, altering the structure of the user table in an e-commerce application's datastore can trigger a cascade of redeployments in other services, such as payments, catalogs, and products.
This not only adversely affects the developer productivity but also the overall customer experience.
Similarly, even if microservices have independent codebases, shared codebases or libraries can pose challenges.
Frequent updates of shared libraries can lead to redeployments of dependent services, rendering microservices inefficient and susceptible to changes.
First and foremost, when decomposing your application into microservices, make sure to group features properly and identify the benefit of parsing it out into an independent unit of functionality. This step helps avoid building tightly-coupled services that rely on synchronous communication and, as a result, induce high latency.
In a microservice architecture, each service should have its own datastore, and services should communicate through APIs. Avoid sharing a single datastore among multiple services, as it creates a strong coupling between them, and changes in one service can affect the others.
To avoid coupling between services, asynchronous communication is a better approach compared to synchronous communication. It allows services to communicate without waiting for a response, improving the overall application's throughput.
Implement an event-driven architecture that helps to avoid direct coupling between services. In this approach, services send and receive events asynchronously, and decoupling happens through the use of an event bus.
In conclusion, distributed monoliths can be an unintended consequence of a poorly planned microservices architecture.
While it may seem like a quick fix to just break down a monolith into smaller services, it's important to keep in mind the potential pitfalls of tightly coupled services and shared resources.
By following best practices such as service decomposition, event-driven architecture, and loose coupling, developers can avoid creating distributed monoliths and reap the benefits of a truly scalable and resilient microservices architecture.
I write about System Design, UX, and Digital Experiences. If you liked my content, do kindly like and share it with your network. And please don't forget to subscribe for more technical content like this.