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

51–60 of 93 posts

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

#51

Post by rorykoehler »

quizotic wrote: post #46

There's a bit of an emperor's clothes problem with microservices. If microservices are never combined together, they are essentially monoliths under a cooler name. But as soon as you combine them, you run into the same problems that are solved by traditional shared database systems. Here are two: cross-microservice referential integrity, and cross-microservice transaction coordination, but there are plenty more. Take…

>But then what happens to the Orders that reference that now old and outdated Customer identity? If changing the Customer microservice breaks the Orders microservice, then what's the point of the separate encapsulation?

Isn't that what append only event sourcing and CQRS is designed to solved?

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

#52

Post by jayd16 »

quizotic wrote: post #46

There's a bit of an emperor's clothes problem with microservices. If microservices are never combined together, they are essentially monoliths under a cooler name. But as soon as you combine them, you run into the same problems that are solved by traditional shared database systems. Here are two: cross-microservice referential integrity, and cross-microservice transaction coordination, but there are plenty more. Take…

You're right that a shared resource like a database does endanger one of the microservice benefits and I think we're on the same page when I say the reality is "this is fine." You still get the benefit of being able to deploy, version, scale and manage a single microservice separately.

You might eventually have to break out the microservice entirely and build it out such that the shared datamodel has to be fully represented in api and not the database. That's fine too. That's a lot of work but you're only closer to that goal when you start with SOA and microservices not further away. Sure, you can get into trouble if you build a large interconnected monolith that you happen to be running in parts across many servers. I would, uh... advise against that. Try to separate your services in natural ways that won't cause massive headaches.

Basically, there are still some benefits and this critique, while valid, only points out what you aren't getting for free. Its not actually a negative.

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

#53

Post by eweise »

ebiester wrote: post #42
eweise wrote: post #17

Earlier quoted context omitted.

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…

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.

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

#54

Post by ec109685 »

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…

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

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

#55

Post by jayd16 »

nqzero wrote: post #36
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 ?

Foreign key constraints seems like an easy example. Not every service needs the power to create and manage user accounts but its nice know that every user id in your datamodel is valid.

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

#56

Post by docker_up »

ec109685 wrote: post #54
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…

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.

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

#58

Post by rorykoehler »

thoman23 wrote: post #43

My understanding is that the point of microservices isn't to just move what would have been a relational join in SQL to an equivalent join in the service layer, which is what the author is implying. Instead, the order service should already have the subset of user data it needs to perform its function. If a user name changes, for example, that would trigger an event that gets consumed by a handler in the order domain…

This is exactly correct and it took me a good while to understand this due to many people either not implementing this pattern or not knowing about it and then giving their 2 cents on microservices. Event sourcing and CQRS is the way to go.

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

#59

Post by gigatexal »

A shared database offers the allure of transactions and persistent state management. But using a traditional RDBMS is not very scalable. Schema changes have hurt us many times. And then what of foreign keys and such. It is nice to be able to consistently open a single transaction and get an answer from the one true source of truth but it quickly becomes the single biggest bottleneck. I prefer the database per service model and leaving a global transaction manager to be implemented if needed. I think it adds much more in flexibility and scalability.

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

#60

Post by gigatexal »

quizotic wrote: post #46

There's a bit of an emperor's clothes problem with microservices. If microservices are never combined together, they are essentially monoliths under a cooler name. But as soon as you combine them, you run into the same problems that are solved by traditional shared database systems. Here are two: cross-microservice referential integrity, and cross-microservice transaction coordination, but there are plenty more. Take…

If you’re putting a foreign key from customers into orders from the customer service into the orders service then the customer service key definition used as a foreign key cannot change.
Post reply on HN