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

81–90 of 93 posts

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

#81

Post by zaarn »

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.

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

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

#82

Post by hvidgaard »

HelloNurse wrote: post #79
hvidgaard wrote: post #69

Earlier quoted context omitted.

If you back your microservice architecture with a shared RDBMS and expect transactional and referential integrity, you've only scaled some parts of your system. Instead you should think about if A: you really need that scale ability, and B: the real implications of it. So, in this customers / orders example what if you delete a customer? Ideally you don't, you keep the customer as long as you need the orders. You cou…

The system can simply mark the "deleted" customer as a former customer and add records of their dismissal without any referential integrity problems. "Deleting" an entity doesn't mean that it should immediately vanish without a trace from the database, leaving a wake of destruction. It's only a business-level change: we won't accept further orders from deleted customers, there might be something nasty to do to their…

Doesn't address the problem of a customer somehow vanishing from the system without notifying dependent services. With at least once message delivery we know that the order service will know at some point, but we need to handle the case in the mean time.

It could also be a possibility that we need to delete customer records pr. GDPR, but need to keep the order records due to other laws, perhaps in an anonymized form.

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

#83

Post by HelloNurse »

hvidgaard wrote: post #82
HelloNurse wrote: post #79

Earlier quoted context omitted.

The system can simply mark the "deleted" customer as a former customer and add records of their dismissal without any referential integrity problems. "Deleting" an entity doesn't mean that it should immediately vanish without a trace from the database, leaving a wake of destruction. It's only a business-level change: we won't accept further orders from deleted customers, there might be something nasty to do to their…

Doesn't address the problem of a customer somehow vanishing from the system without notifying dependent services. With at least once message delivery we know that the order service will know at some point, but we need to handle the case in the mean time. It could also be a possibility that we need to delete customer records pr. GDPR, but need to keep the order records due to other laws, perhaps in an anonymized form.

Are you advocating sending and processing notifications about customer changes so that the order component can maintain redundant stale copies of customer data? Why would one do that instead of an appropriate and selective query when e.g. a new order is being entered?

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

#84

Post by virgakwolfw »

Nobody splits databases because of encapsulation. DBMSes have encapsulation functionality built in. Databases are split because a single DB instance (Oracle RAC explodes and causes billions in lost sales) cannot support the workload. Most other reasons is because of fashion without understand Why. Most companies don’t have this problem. They’re inventing shiny problems and come up with excuses to work on them.

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

#85

Post by hvidgaard »

HelloNurse wrote: post #83
hvidgaard wrote: post #82

Earlier quoted context omitted.

Doesn't address the problem of a customer somehow vanishing from the system without notifying dependent services. With at least once message delivery we know that the order service will know at some point, but we need to handle the case in the mean time. It could also be a possibility that we need to delete customer records pr. GDPR, but need to keep the order records due to other laws, perhaps in an anonymized form.

Are you advocating sending and processing notifications about customer changes so that the order component can maintain redundant stale copies of customer data? Why would one do that instead of an appropriate and selective query when e.g. a new order is being entered?

For a MSA system, yes it should maintain just enough knowledge about customers to work, not everything. For instance it does not need to know the customers name, just the id. Systems that query the orders can query the customer component for additional data.

The denormalization and distribution of redundant data is required for it to scale. If you make the order component query the customer component, you haven't solved the problem from the other way around, and suddenly you have a hard coupling where a transient failure in one component automatically fails the other.

It might not be a tradeoff you're willing to make, but then you probably do not need the scaling - at least not along that vector.

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

#86

Post by cynicalreason »

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…

Without sounding condescending, but as a very late 'bloomer' - only working in development/software for 3 years and aiming towards an application architect role - I always thought this was the consensus.

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

#87

Post by aedron »

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…

Yeah, microservices and event sourcing go hand in hand.

Each microservice maintains its own database, with a model that is tailored to its own domain. This is called a projection, to illustrate that it is really the service's own view on the world, often with redundancy of data.

The service sources just the events it needs, and stores only the data it needs, to maintain this projection. It handles domain object lifecycle events in the way that makes sense for that particular service.

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

#88

Post by Oras »

If you can't split your databases then maybe you don't have a correctly established domain? There is no point of doing microservices when you still have tightly coupled data and you don't know how to split them efficiently. Monolith is not bad if it is well structured, tested and maintainable. Otherwise, you'll have to change multiple services for adding a new field of data.

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

#89

Post by Izkata »

cynicalreason wrote: post #86
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…

Without sounding condescending, but as a very late 'bloomer' - only working in development/software for 3 years and aiming towards an application architect role - I always thought this was the consensus.

It's similar to the "unit" in "unit testing": people will relate the most basic meaning to something they already understand, resulting in different, subtle distinctions.

In this case the breakdown actually seems the same to me as with the common unit testing misunderstanding - breaking down by syntactic form instead of conceptual form.

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

#90

Post by karmakaze »

sigi45 wrote: post #25
karmakaze wrote: post #11

Earlier quoted context omitted.

This is the most important point when making microservices. There's lots of talk about bounded contexts but very little about how to draw the boundaries. Most are superficial and repeat bad examples like OrderService (order is both a verb and boun, OrderingService sounds ok). Using two part service names (ContentComposition, MessageDelivery) usually works out well. As to the shared db aspect, while spitting a miniser…

Why would you make Miniservices?

We never had the intention to make miniservices. Some were microservices that acquired abilities that grew to become separate microservices. On other projects they were prototypes that lasted long enough and became small monoliths to get split up.
Post reply on HN