Modernizing a 10-year-old legacy system, dev says 'microservices' — is this the right call for a small product?

Your dev is probably just looking to pad their resume with trendy architectures. 1,200 users can easily run on a single optimized server with a standard relational database. Having three people try to manage microservices will at least double your delivery timeline.

We made the exact same mistake last year with a 4-person team. We split our system into five microservices, and our first 6 months were completely wasted troubleshooting inter-service network and serialization bugs. Our cloud bills shot up from $400 to $2,300 a month. In the end, we rewrote it back into a modular monolith, and our feature velocity literally tripled.

Going the microservices route means writing a lot more than just product code. You have to build out service discovery, message queues, distributed logging, and distributed transactions. Since you're splitting the database too, even a basic SQL join turns into multiple API round trips across services. Without a full-time DevOps engineer on the team, your app won't get faster—it'll grind to a halt.

Follow these three steps for the rebuild: 1) Clean up your current database schema and map it directly to core domain models, 2) Structure your codebase with microservice discipline using clear folder boundaries, but keep it in a single project (a modular monolith), 3) Write comprehensive unit and integration tests to de-risk the production rollout.

we jumped into this hype two years ago too... one service going down took down the whole chain tracking logs was pure hell.. then modular monolith is the way to go for smal teams, zero need for the drama.

But if we build a monolith won't we have to throw the whole thing away when our user count hits 10k or 50k down the line? Aren't we capping our own growth?

Even 50k users can run smoothly on a single well-tuned server. Massive global SaaS platforms processing millions of transactions still run on modular monoliths. If a specific bottleneck emerges later, you simply peel off that one module into a standalone service. There is zero benefit to building a distributed system prematurely.

Given your available budget and team size, a modular monolith is the most rational choice from a risk management standpoint. Channeling your resources into core business features rather than infrastructure orchestration will directly maximize your ROI.

Let me clarify the technical side. Hasty decisions become decisions you have to fix six months later.

Correct me if I'm wrong.

generally correct but one part is missing. honestly hasty decisiions become decisions you have to fix six months later.

this thread is archived.

Noted, thanks. Just because everyone does it doesn't mean it's right.

I'm also curious if anyone does it differently.

nooted thanks.

There's also a measurement aspect to this. Everything goes well for the first three months; problems arise in the fourth.

If you have questions, write them; I'll answer as best I can.

I didn't know that.

I went through the same thing.

Let me speak from the other side; I'm on the supplier side. Just because everyone does it doesn't mean it's right.

Taking notes for two weeks yields better results than a six-month estimate. Correct me if I'm wrong.

Let me summarize what's been said so far. If you get three different answers on a topic, the question was asked wrong.

Proven by experience.