Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is a shared database in microservices actually an anti-pattern?

hackernoon.com

Post reply on HN
Print view View original

31–40 of 93 posts

Re: Is a shared database in microservices actually an anti-pattern?

#31

Post by barrkel »

If your problem could be solved with buy rather than build, for services that you buy (e.g. could conceivably exist via AWS in your perfect world), then microservices may be a smart idea - if you can fork off a team to own that ideal service, you can eat the integration costs because you don't need to deal with the complexities of keeping that service running, it doesn't add to the total cost of ownership of getting your code running in production, it's just another remote API with an SLA.

In that situation, the other services sharing your database is madness. Of course they shouldn't use your database. If they did, it would mean you're responsible for their load; you'd need to balance your needs with their needs. When your database goes down, their service and its clients (that you don't need to know about) would also go down. No good at all. Don't do that.

And if you're not in a situation where different teams are responsible for different microservices, you probably shouldn't be using microservices.

Re: Is a shared database in microservices actually an anti-pattern?

#33

Post by ChicagoDave »

taffer wrote: post #27
gcufhg wrote: post #24

Earlier quoted context omitted.

You can for the start use a single database as long as the different services don't use / know about each others tables. Then again you could just use separate db's.

Sure, but as I said, if you split your database, you have to deal with transactions, joins, consistency, over- / underfetching. All this leads to complexity and performace issues you wouldn't have otherwise.

Reliable messaging and eventual consistency eliminates the need for transactions. Performance can be a mitigating factor. Joins are for reporting. In the cloud, performance is just a cost factor.

Re: Is a shared database in microservices actually an anti-pattern?

#34

Post by acdha »

jrochkind1 wrote: post #29

What if microservices are actually an anti-pattern?

Anti-pattern is strong but I’d go with premature optimization because most developers grossly overestimate their ability to create the correct architecture ahead of time and underestimate the performance, maintenance, reliability, and security costs. Most of the times I’ve seen a $$$ app struggle to match 90s single-server app performance it’s been because the team was struggling under the weight of unnecessary architecture.

Re: Is a shared database in microservices actually an anti-pattern?

#35

Post by sauceop »

taffer wrote: post #5

Completely agree with the article. If each piece of code has its own data store, you lose all the advantages of the DBMS: you have to handwrite your joins, your transaction system and get all sorts of problems with cache invalidation, data inconsistencies and n+1 fetching. Encapsulation is important, but there are better ways to do it, such as using the authorization system of your DBMS.

Agreed, I think the issues you're touching on are fundamentally difficult problems that don't have a single solution. For example.

* storing complex data and supporting multiple access patterns efficiently (like joins) is hard and involves trade-offs (e.g. normalisation vs denormalisation, benefit vs overhead of indices).

* data consistency is hard, particularly once you are at a scale that requires distributed storage

* durability and disaster recovery is hard

* failover and availability, particularly for a stateful system, is hard

The right solution is completely application dependent. Usually the best approach is to avoid hard problems to the extent your application allows it, e.g. by accepting relaxed consistency, partitioning the data, or limiting the use cases the system supports. Then you can outsource the hard problems that remain to an existing solution (e.g. a transactional database).

Microservices help address some of those problems, but you need to recognize when they don't (e.g. you need strong consistency across multiple services) and adjust your designs accordingly

Re: Is a shared database in microservices actually an anti-pattern?

#36

Post by nqzero »

taffer wrote: post #5

Completely agree with the article. If each piece of code has its own data store, you lose all the advantages of the DBMS: you have to handwrite your joins, your transaction system and get all sorts of problems with cache invalidation, data inconsistencies and n+1 fetching. Encapsulation is important, but there are better ways to do it, such as using the authorization system of your DBMS.

could you give an example of what data would belong in distinct microservices but need to be joined or need transactional semantics ?

Re: Is a shared database in microservices actually an anti-pattern?

#38

Post by NicoJuicy »

barrkel wrote: post #30
ChicagoDave wrote: post #9

Earlier quoted context omitted.

The only thing that needs a relational data store are reports. Operational data stores should only be concerned with their own domain and expose behaviors and events. There are exceptions, but if you’re building a complex system, monolithic architectures have a known lifetime while MSA’s tend to mitigate long term coderot. It’s hard to see this until you’ve built domain driven micro service based systems properly.

The trouble is, if you push state into different services behind APIs, you end up reinventing 50 to 80% of RDBMS anyhow. You need transactions, replication, indexing, integrity, backups etc. etc. You can use an event stream (a substitute for a commit log) but then you need to migrate your event stream, be able to undo events in the stream, etc. It's complexity you really ought to avoid unless you need it for serious…

> multiple teams working concurrently without stepping on each other, and microservices serve an organizational purpose rather than an architecture purpose.

I so hard agree with this.

Re: Is a shared database in microservices actually an anti-pattern?

#39

Post by zepolen »

pritambarhate wrote: post #14

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 wit…

> 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...

Re: Is a shared database in microservices actually an anti-pattern?

#40

Post by taffer »

ChicagoDave wrote: post #33
taffer wrote: post #27

Earlier quoted context omitted.

Sure, but as I said, if you split your database, you have to deal with transactions, joins, consistency, over- / underfetching. All this leads to complexity and performace issues you wouldn't have otherwise.

Reliable messaging and eventual consistency eliminates the need for transactions. Performance can be a mitigating factor. Joins are for reporting. In the cloud, performance is just a cost factor.

Eventual consistency makes everything even more complicated and I am by far not the only one who says so [1].

[1]: https://cloud.google.com/blog/products/gcp/why-you-should-pi...

Post reply on HN