Adding micro-services is the way to make the company bankrupt.

"micro-services" is the worst solution to ANY problem. Is not a solution, only another way to write a problematic app.

The problem here is complexity and "micro-services" is the MOST efficient way to add complexity.

And the real problem here is complexity X scalability, which requires simplicity and tunning, stuff that "micro-services" IS NOT mean to solve.

---

I work in the enterprise space, and you bet you can cut 70%* (every time you find stuff like this) of the code and stay single-master-DB even for some very large companies if you have a half-decent architecture.

p.d: Do note that cut code does not mean the app will end with just 30%, is just that 70% is trash to be redone.

Are you saying that every company up to a certain size should have a single master DB?

Unfortunately the word “microservices” on HN brings out some low-quality discourse. Maybe this time will be different?

For this particular instance and company, no. Not because microservices can't work, but instead because of the coordination required between services/api/database that doesn't appear to exist at all in this company.

This said, depending on your application and how it's split up quite often there are easy wins. An example I've seen is a company that had a huge batch reporting jobs for reporting at fixed intervals. Hammered the hell of out production, so was moved to pull data from a read only replica.

It really depends on what they are doing. At this stage, I'd suspect it needs some major rearchitecture, but they accumulated so much tech debt it's difficult to say what next steps could be. As was pointed out by others, starting by introducing some strong governance practices would be a good start.

My department was in a bad single-DB position like this. The only way out was big rewrites, and generally each team had one service with its own DB in the end. Dunno if you'd call that microservices or not.

I would if they can have their own release cycles.

Then yes

The important thing in these convos is to be clear each time what you mean by "microservices," because there isn't a solid definition for that. I've seen too many debates at work over whether we should use microservices, where both sides already agree on the actual design.