From Monoliths to Modularization: Knowing When to Break the Mold with Microservices and MFEs

Georges Akouri-Shan
3 min readDec 24, 2024

--

The monolith ruptures

Imagine a platform where hundreds of engineers are pushing code into the same repository daily. I faced that reality some years back. Dozens of teams, each with their own product and engineering priorities, working within a sprawling monolithic codebase.

The result? Absolute madness! Constant deployment risks, bugs at every turn, and a growing number of missed SLAs.

Why Monoliths To Begin With

At first, monoliths can make sense. Early-stage startups with one or two developers often choose a monolith. With a single codebase, development, debugging, and deployment are simplified, making it easier to test end-to-end without worrying about coordinating across multiple systems.

Even as that team continues to grow, a monolith helps streamline recruitment, onboarding and collaboration, allowing everyone to focus on productivity rather than managing complex integrations. By centralizing everything in one place and in a single programming language, teams can minimize early technical debt and move quickly — critical when speed to market matters most.

But as the engineering headcount continues to grow alongside the company, the cracks in the monolith begin to show.

The Cracks in the Monolith

Monoliths often start strong but, as the system and the team scale, the benefits quickly turn into liabilities:

  • Increased Code Complexity: You change the color of a button but take down the entire payment flow and no one knows why.
  • Slower Development Cycles: Now your development is slower because every change — No matter the size — requires months of testing.
  • Increased Risk of Downtime: Due to this system’s fragility, deploying a change feels like playing Russian roulette. You just hold your breath hoping something critical doesn’t break.
  • Scaling Challenges: Adding developers doesn’t always mean faster progress — in monoliths, it often means stepping on each other’s toes. More people, same codebase, and diminishing returns.

As the cracks deepened, it became clear that solving these issues required more than incremental fixes. We needed to rethink how we structured our system — both the frontend and backend.

A Shift Toward Modularization

Fixing the cracks in the monolith meant tackling two major fronts: the backend and the frontend. In most cases, you can’t just break one apart and call it a day — they’re too tightly connected.

On the backend, microservices gave us a way to break down complex dependencies and scale specific functions independently. Teams could focus on owning smaller, domain-driven services without worrying about stepping on each other’s toes.

On the frontend, microfrontends (MFEs) gave us the freedom to rethink the UI. No more one-size-fits-all JSP templates running thousands of lines long. Instead, teams could build and deploy their own pieces of the user experience independently — faster, cleaner, and without being held back by the backend.

Monolith to Modularization: different architectural strategies for frontend & backend development
Monolith to Modularization: different architectural strategies for frontend & backend development

There are a few different strategies when it comes to breaking down monoliths. One could go from a single monolith to two, modularize the front or back, or modularize both. Given our circumstances at this time, microservices and MFEs were the key to scaling effectively, reducing risk, and giving teams the autonomy they needed to move quickly.

Looking Ahead

Breaking up a monolith is a journey that started with the backend. We focused on identifying key APIs to decouple into microservices, laying the foundation for a more scalable architecture. From there, we turned to the frontend, where moving to microfrontends unlocked even more flexibility for our teams.

In the next posts, I’ll dive deeper into both transitions — how we approached backend modularization first, what made it work, and the lessons we learned along the way. Then, we’ll cover how we tackled the frontend and why a phased approach to MFEs was critical to keeping users and teams happy throughout the process.

Breaking a monolith isn’t easy, but with the right plan, it’s more than worth it. Ready to see how we tackled our first modularization challenge? Read the next post: Rebuilding Authentication with Microservices.

--

--

Georges Akouri-Shan
Georges Akouri-Shan

Written by Georges Akouri-Shan

Engineering leader in a rapidly changing world, writing so something sticks.

No responses yet