---
title: 'Moving from a Rails Monolith to Microservices: Things to Consider Before You
  Regret It'
teaser: Learn what to consider before breaking up your Rails monolith into microservices.
tags: microservices,architecture,development,devops
author: Rob Whittaker
published_on: 2025-05-09
---

Let’s get this out of the way early. Moving from a Rails monolith to
microservices is like trading in a bike for a unicycle and a skateboard. Yes,
you can still get where you’re going, but you’ve made the journey harder in the
name of imagined flexibility. Of course, these aren’t the only two architectural
options out there. But for many teams, the conversation often centres on this
particular shift. And when it does, it’s worth asking: is this a step forward or
sideways?

Yet here you are. The team is grumbling about boundaries. Deployments feel
heavy. Someone read a post, went to that conference talk, or copy-pasted the
Spotify org chart into Notion. And now, as CTO, you’re asking, “Should we break
up the monolith?”

As a consultancy that’s seen both sides, here’s our take: it’s usually best to
start with a monolith. For many teams, the added complexity of microservices
doesn’t pay off. There are cases where it does. For example, when a system needs
different architectural characteristics or needs to scale. Martin Fowler
suggests that [a monolith gives you the fastest path to understanding][]. You
should consider breaking things apart only once you’ve hit real friction.
*Fundamentals of Software Architecture* by Mark Richards and Neal Ford echoes
this idea. The authors emphasise evaluating tradeoffs based on system needs, not
hype.

## Rails Is a Monolith Friendly Framework

Rails shines brightest when you embrace its opinionated nature. Convention over
configuration, batteries included, everything close to hand. It optimises for
*velocity*, *cohesion*, and *simplicity*. These qualities are compelling for
small teams moving fast. Of course, those strengths come with tradeoffs. As a
monolith grows, complexity and coupling can increase. You may sacrifice
scalability, elasticity, and fault tolerance compared to a distributed
architecture. Rails' advantages outweigh its constraints for teams in the early
to mid stages.

The Rails monolith is not a flaw. It’s a feature. It allows a small team to ship
and scale. Most performance issues don’t come from monolithic architecture. They
come from premature optimisation, unindexed columns, and complicated
abstractions.

So, if you’re looking to split the app for speed, ask yourself: “Is the app’s
size the problem, or are we misusing our tools?”

## Microservices Multiply Everything

In a monolith, a change is a `git diff`. In microservices, a change can become a
coordinated dance between distributed systems. For example, when the services
are too granular, they cannot do meaningful work. Testing gets harder.
Deployments become orchestrated events. Local dev environments turn into
part-time jobs. When microservices aren’t independent, you’re not gaining
autonomy. Instead, you’re adding network latency and operational overhead.

You’re not adding services. You’re adding *surfaces* for failure. You’ve gone
from method calls to network calls. You will track bugs across services, syncing
schemas, and untangling observability spaghetti.

That is the real cost of microservices, and if you don’t have a specific, urgent
reason to bear it, don’t.

## Okay, But You’re Doing It Anyway

We get it. Sometimes, organisational reality trumps architectural purity. But
it’s not only politics or team structure. There are also genuine architectural
needs that can make microservices the right choice. Parts of your system need to
scale. Fault isolation is critical. Different components have very different
lifecycle needs or languages. These aren’t edge cases. They’re valid reasons to
reach for a distributed architecture. The key is to make sure the benefits
outweigh the costs.

You’ve hit team size limits, where working in the same codebase is a liability.
Regulatory needs demand strict service boundaries. Parts of your system do
scale, which is fair enough.

If you’re going to break things apart, do it with care:

### Start with clear boundaries

Don’t split by model. Split by domain. Think in [vertical slices][]: product
search, billing, and notifications, not horizontal layers. Use the language of
DDD if you must. Avoid building “microservices” that are “tiny Rails apps
talking to the same Postgres.”

### Treat your monolith as the first service

Don’t kill the monolith. Refactor it into a platform. Let it expose clear
interfaces. Avoid creating the dreaded *distributed monolith*. You don’t want
services coupled with implicit contracts and lousy documentation.

### You’ll need infrastructure maturity

Docker, CI/CD, service discovery, logging, tracing, API management. These aren’t
nice-to-haves anymore. If you don’t already have a DevOps culture (or team),
you’re about to grow one, whether you like it or not.

## So What’s the Alternative?

Before you jump to microservices, consider the following:

-   **Modular monoliths:** Break your app into engines or namespaces. Enforce
    boundaries in code, not on the network. It sets the stage for approaches
    like [the citadel model][]. As complexity grows, a “majestic monolith”
    develops to have more defined internal walls.

-   **Service objects and interactor patterns:** You can isolate
    responsibilities without reaching for a queuing solution.

-   **Extract read-heavy endpoints first:** A read-only API service (for
    reporting or public data) is a safe, low-risk place to practice.

## Final Thought

Monoliths aren’t only for MVPs. They’re for products that value maintainability,
quick iteration, and developer happiness. That’s where Rails came from. Of
course, a sprawling monolith can slow you down as much as it once helped you
move fast. For example, if it slips into “ball of mud” territory. But the
solution isn’t always to reach for microservices. Rails gives you the tools to
keep things clean and cohesive. Please don’t throw away your most significant
advantage by chasing architecture.

But if you’re going down this road. Do it with eyes wide open and build escape
hatches. You might want to come back.

[a monolith gives you the fastest path to understanding]: https://martinfowler.com/bliki/MonolithFirst.html
[the citadel model]: https://signalvnoise.com/svn3/the-majestic-monolith-can-become-the-citadel/
[vertical slices]: https://thoughtbot.com/blog/break-apart-your-features-into-full-stack-slices