We Run a Monolith and We're Not Sorry

We Run a Monolith and We’re Not Sorry is a position, not a hedge.

Microservices are a scaling solution for organizations, not technology. Here’s why a Rails monolith serves Miru perfectly. We write from operating experience, not trend-chasing.

The Microservices Sales Pitch

The pitch for microservices goes like this: break your application into small, independently deployable services. Each service owns its domain. Teams can deploy independently. You can scale individual services based on load. It’s cleaner. It’s modern. It’s what Netflix does.

Here’s what they don’t mention in the conference talk:

You now have 12 services that need to communicate over the network. Network calls fail. So you need retry logic, circuit breakers, and timeout handling. You need distributed tracing because a single user request now touches six services and debugging means correlating logs across all of them. You need a service mesh or API gateway. You need 15 YAML files per service for Kubernetes. You need a team just to manage the infrastructure.

A bug that would have been a 10-minute fix in a monolith — follow the stack trace, find the method, fix it — becomes a two-hour investigation across three repos with different deployment schedules.

That’s not simplicity. That’s distributed complexity wearing a clean architecture t-shirt.

What Actually Scales

DHH wrote about this years ago in “The Majestic Monolith.” His argument was simple: microservices are a scaling solution for organizations, not for technology. When you have 500 engineers who can’t all work in the same codebase without stepping on each other, microservices make sense. It’s a people problem, not a technical one.

Miru has a team of 15. We all work in the same codebase. We know every corner of it. When something breaks at 2 AM, anyone on the team can debug it because there’s one application to understand, not twelve.

Our deploy takes 90 seconds. Push to main, CI runs, green means ship. No coordinating releases across services. No checking if the invoicing service is compatible with the new version of the users service. No service dependency graphs.

Our database is PostgreSQL. One database. Joins work. Transactions work. Foreign keys work. We don’t need eventual consistency because we have actual consistency. Rails 8 gives us Solid Queue for background jobs and Solid Cache for caching. No Redis cluster. No RabbitMQ. No Kafka.

When Microservices Make Sense

I’m not anti-microservices as a concept. They make sense when:

• You have hundreds of engineers and genuine team coordination problems
• You have components with radically different scaling profiles (like a real-time chat system next to a batch processing pipeline)
• You’re Netflix, and you literally invented the tooling

If you’re a team of 5-50 building a SaaS product, a monolith will serve you for years. Probably forever. Basecamp runs on a monolith. Shopify ran on a monolith until they had thousands of engineers. Hey.com is a monolith.

The Boring Advantage

The best technology decisions are the boring ones. A Rails monolith with PostgreSQL is boring. It’s been boring for twenty years. And in those twenty years, it’s powered millions of successful applications while the microservices crowd spent their time debugging network partitions and writing Kubernetes manifests.

We chose boring because boring lets us focus on the product instead of the infrastructure. Our customers don’t care how many services we run. They care that their invoices go out on time and their time entries are accurate.

Miru is a monolith. It deploys in 90 seconds. It’s debugged with one log file. And we’re not sorry.

Hard Stop

If you agree, build this way. If you disagree, test the opposite and measure the real cost.

Start with Miru or read the docs.

Vipul A M

Co-founder at Saeloun. Building Miru. Rails contributor. Shipping from Pune, India.