Nah this doesn't work out. Because requirements are so chaotic and modular design isn't an axiomatic science things will for sure go wrong with the design both because you got the design wrong and because the requirements shifted to a point where another design was better.

You encapsulated data under one service and you find that it's actually utilized much more in another service. This happens a lot.

The longer you can centralize your storage the better and easier everything is.

Exactly. And having more than one source of truth for your data complicates a lot of things.

Where I work we run a massive MySQL database that has a pretty simple sharding rule, so I don't believe that you need to split the database even at scale.

It's not primarily about the size of the DB, it's about what's in it. If your massive MySQL DB is only used by one team, then that's fine. If separate teams' services are speaking through shared tables on it, that becomes a mess of an API easily.

We have thousands of developers on it. I’m not saying it’s a silver bullet, but it works and it works well. Also, the service writing on it is only one (monolith).

Depending on what the service is, I can see how this would work fine, but I don't think this is a common case.

Except I've seen this work at dozens of companies?

This thread is very painful, feels like CS101 coming in to tell us why we don't need relational databases and that we can just shove it all inside mongo.

It's not the thread it's most likely you. I don't know if people tell you but dealing with you is likely to be extremely painful if you say rude garbage like this to peoples faces.

Multiple databases can "work" but you get the problem I described above.

You know when you go to a company and eventually you see idiot practices or technical debt? Unfortunately this belongs to that category. You seeing it at dozens of companies doesn't validate anything except for the fact that bad patterns are common.

It also validates the existence of people who often do things poorly and don't know it (aka you).

Multiple DBs does work, and large orgs do it this way with good results. But I'm not here to insult people for disagreeing. It's just software, nothing to get heated over.

No worries. You didn't call the thread painful. That kind of comment causes heat. It doesn't belong here.

Of course it "works". But you can do better.

Splitting data into several dbs when one db suffices is called "extra work". Good results can arise from "extra work". But the extra work wasn't necessary.

You have to think like this: Sure multiple dbs work. But would 1 db in it's place work just as well?

The top commenter here from Netflix one of the people who promoted the whole microservices thing is telling startups to go monolith for a reason.

Our large org is familiar with the 1 DB approach, cause that's what we held onto until it became blatantly necessary to jump to microservices. Even our subteam is feeling the need to divide up our service because its scope has kept expanding.

Startups shouldn't start with microservices. I've worked for a few different ones, and I've always created a monolith while avoiding all kinds of premature planning. Doesn't mean I'd run things that way with 200 people owning systems with evolving requirements for 10+ years, or even two separate dev teams of 5 people.

Right. But you likely split the db for performance not just for decoupling data and code. Microservices is an option for scaling. My argument is more against it as a way to decouple and organize logic.

Performance wasn't the issue; mono DB was actually fast enough. Multiple teams' services sharing tables became effectively a fragile API between them with hidden dependencies. New business requirements were introducing widespread breaking changes, and the org relied too heavily on a few experts who understood it all. Plus, schema changes were behind a ton of red tape since they affected everyone.

Also if by "decoupling data and code" you mean decoupling data from code, that's not the goal. It's to decouple one team's data from another team's data, and to properly abstract it.

The only reason our mono-DB even lasted this long was because previously, very few requirements were changing over time. So when people say their big org is monolithic, I can believe it. It works in some scenarios, in most it doesn't.

>you mean decoupling data from code, that's not the goal. It's to decouple one team's data from another team's data

Use a schema bro.

You can do this with two schemas. Think of it as folders in databases. Then give different permissions to users per schema.

Our DBMS doesn't support schemas, but our team's services just use separate tables with separate ACLs. I think of those cliques as separate databases cause it's basically the same thing.

It can also have multiple "databases" on a single running instance, each with separate quota and ACLs. So each team uses its own database. Only a few teams are special enough to need a dedicated instance.