Why you should stop building microservices and look at elegant monoliths

Stop The Over-Engineering Madness: Why Your Future Is An Elegant Monolith (And Why Microservices Are Making Us All ‘Edan’)

By the Resident Tech-Shaman of the Binary Jungle

The “Wong Edan” Manifesto: Why My Brain Is Buzzing Like a Faulty Circuit Board

Listen up, you beautiful, over-caffeinated architects of digital chaos! Your resident Wong Edan is back, and today, my brain is vibrating at a frequency that suggests we’ve all lost our collective minds. We’ve been chasing the microservices dragon for years, thinking it’s the promised land of “scalability” and “agility.” But let me tell you, I’ve seen things. I’ve seen developers weeping over network latency, and DevOps engineers performing ritual sacrifices to Kubernetes clusters just to get a “Hello World” to talk to a database.

The tech industry has a habit of ditching the “old” for the “shiny” without asking if the shiny thing actually works for the problem at hand. We ditched monoliths because we were afraid of a total collapse. We thought, “Instead of a big building, let’s build smaller buildings, each with just one floor.” (Sound familiar? That’s the April 2025 perspective on our industry’s collective anxiety). But here’s the cold, hard truth: those one-story buildings are creating a neighborhood that’s impossible to navigate. It’s time to look at the elegant monolith before we all end up in a padded cell.

1. The Fallacy of the One-Floor Building

According to recent industry reflections (April 19, 2025), the primary motivation for ditching monoliths was to avoid a catastrophic collapse—the idea that if one part of the building falls, the whole thing goes down. This led to the microservices explosion: the “one-floor building” strategy. But ask yourself: is a city of 500 one-story shacks actually better than a well-engineered skyscraper?

When you split everything into pieces so small that you lose the “big picture,” you aren’t scaling; you’re fragmenting. If you start building your microservices by splitting everything into pieces so small that you end up with hundreds of independent entities for a simple application, you are inviting a different kind of collapse—the collapse of management. A monolith doesn’t need a complex service mesh just to find out where the “User Profile” lives. It’s right there. In the code. Imagine that!

2. The MVP Death Trap: Speed vs. Over-Engineering

Let’s talk about real-world stakes. I was looking at a case study from November 2025 regarding two Fintech startups. One was facing a “do or die” situation: they needed an MVP by the end of the year. The instruction was clear: “If we don’t show something working, the whole initiative is dead.”

In this high-pressure environment, microservices are a death sentence. To pull off a successful launch under a tight deadline, the monolith is your only true friend. Why? Because the overhead of microservices—setting up CI/CD pipelines for 20 services, handling inter-service authentication, and managing distributed logging—will eat your entire development cycle before you even write a single line of business logic. If you want to show something working by the end of the year, you don’t build a distributed system; you build a working application.

3. The Hardest Part: It’s All About Your Data

Here is the “Edan” truth that many “expert” consultants won’t tell you: the hardest part about microservices isn’t the code; it’s your data. As pointed out as far back as July 2016, your domain and your data will ultimately determine the success of your architecture. For an “enterprise” building microservices, we need to make some very tough choices about data ownership.

In a monolith, data consistency is “free” via ACID transactions. In microservices, you are entering the world of “eventual consistency,” which is just a fancy way of saying “I hope the data is right eventually, but I’m not making any promises.” If you haven’t mastered your domain and your data boundaries, moving to microservices will just turn your database into a distributed dumpster fire. You must look at your domain first. If you can’t identify the business boundaries in a monolith, you certainly can’t do it in a microservices environment.

4. Don’t Start with Microservices in Production

There’s a dangerous myth that you should “start” with microservices to be ready for scale. This is madness! As we’ve seen in architectural post-mortems (Dec 2021), starting with microservices in production is a recipe for failure. Monoliths are your friend during the discovery phase of a product.

A monolith allows you to refactor quickly. If you realize that “Service A” and “Service B” actually belong together, in a monolith, that’s a simple move of some files and classes. In a microservices architecture, that’s a multi-week migration project involving API deprecations, data migrations, and infrastructure changes. Don’t build a distributed system for a problem you don’t fully understand yet.

5. The Elegant Alternative: Modular Monoliths and Single Repos

So, what is the “Elegant Monolith”? It’s not a “big ball of mud.” It’s an architecture that embraces modularity without the tax of distributed systems. Look at the Go community’s approach (April 2019): building microservices or elegant monoliths in a single repo. You can have one binary, but that binary is composed of a number of different modules or repositories.

This approach gives you the best of both worlds. You have clear boundaries and module isolation, but you deploy a single unit. You avoid the “distributed monolith” anti-pattern where you have all the downsides of microservices (network latency, complexity) and none of the benefits (independent deployability). By using a single repo for multiple modules, you maintain developer sanity while keeping your options open for the future.

6. When NOT to Do Microservices

Christian Posta has argued that we should embrace design patterns that allow us to start by looking at what’s already out there rather than building from scratch. If you’re going from a poorly designed monolith to microservices, stop right there. Give up now and save your company some money. A poorly designed monolith will only become a poorly designed distributed system.

Before you even think about microservices, you must identify what the business actually does. If you can’t map out the business capabilities, your microservices will be arbitrary and brittle. You might start with something simple, like a Cron Scheduler microservice or an event trace service, as suggested by Rafael Jesus (Sep 2016), but don’t let that be the gateway drug to “building the next monolith” by accident—a tangled mess of services that are logically coupled but physically separated.

7. Technical Debt and the “Next Monolith”

There is a peculiar irony in the tech world: in our quest to avoid the “next monolith,” we often build something much worse. We create services that are so tightly coupled that you have to deploy five of them at once just to change a button color. That’s not microservices; that’s a monolith with a network cable in the middle of it.

The goal should be to look for the things a business does. Identify the core domains. If you can build these as clean, isolated modules within an elegant monolith, you have won. You have achieved the “separation of concerns” without the “separation of sanity.”