Hacker News Reader

Comment by pritambarhate | Hacker News Reader

Yes, shared database is an anti-pattern in micro services architecture.

If one shared database can serve your system well then you don't need microservices. You should build a monolith instead.

The main reason for using microservices is scale. First ability to scale development teams and secondly ability to scale the infrastructure. With microservices you get vertical sharding out of the box. Yes it means dealing with eventual consistency for at least a few usecases. But any system that wants to serve millions of concurrent users needs to deal with eventual consistency as some sort of vertical or horizontal sharding is necessary at that scale anyways.

View on HN

The issue isn't about microservices, its about isolating dependencies between various components of the system. When any part of the system can reach into the user table then you've created a big ball of mud. Even with a monolith, you should have a defined contract between the user service and the rest of the system. That way you can start with a monolith and move to microservices later as needed. You can also change the underlying persistence layer without disrupting the rest of the system. You could for instance start with mongodb for user information while other system components use postgres. If sometime later you think postgres handle json just as well, no problem switch user over to postgres and the rest of the system is unaffected.

You should really build your monolith in a similar fashion to microservices, just leave out the remoting layer.

For Insert/update/delete, that makes sense.

However, many times it makes sense to just do the join in the database rather than make an n^2 join in user space. This becomes problematic in collection cases - 100 cases belonging to 70 users. It's a quick left hand join but a slowdown in application space.

I don't disagree but I think in practice you're probably dealing with a single user at a time when working with orders. A query that referenced n users plus their orders is probably a reporting type query that could be supported in a data warehouse where all the tables could be joined together.

> query that referenced n users plus their orders is probably a reporting type query

No, there are enough other valid cases, e.g. display last customers and their orders or some simple "others have also bought". In practice you will need to join a lot spontaniously and can not just defer that to a data warehouse.

Most stores of large scale do not run online calculation or modeling for “others also bought”. It’s usually offline.

"Show content your friends liked" is an easy example where you want an in database join, in userspace this operation would be incredibly slow.

In Postgres you can use a foreign data wrapper to do such a join with a wide number of 3rd party data sources.

https://wiki.postgresql.org/wiki/Foreign_data_wrappers

> First ability to scale development teams

Except the scaling breaks down because suddenly everyone is bound by tight apis making change very very hard. The potential for services written in entirely different languages makes reallocating dev power less efficient.

> Secondly ability to scale the infrastructure

Anyone who's run a bunch of microservices in production will tell you this is a lie, it becomes a constant whack the bottleneck microservice mole. Not to mention the operational overheads of managing multiple microservices.

> Yes it means dealing with eventual consistency for at least a few usecases

> With microservices you get vertical sharding out of the box

Wtf...

"If one shared database can serve your system well then you don't need microservices".

Exactly, nobody is even thinking about it anymore because "Twitter has microservices, Netflix uses MSA".

Microservice architecture comes with a cost, like more complex deployment strategy (there are more dependencies) and overhead in transaction management, not to mention debugging a problem which hits multiple domains/services.

> The main reason for using microservices is scale

What enables this scale is the encapsulation you get with microservices. You lose this with a shared database. You get a similar problem with multitenancy because "isolated" microservices are impacted by what unrelated services do, so there's a loss of resiliency.

How many services actually have millions of concurrent users? That’s 100k req sec or so, which is a crapton.

Most companies don't need microservices. But the largest ones that are global definitely do.

Probably less than 1% of corporations deploying microservices actually have a load that justifies microservices.

Reply on news.ycombinator.com