Is a shared database in microservices actually an anti-pattern? • Hacker News Board

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

#91

Post by geezerjay » Mon, Feb 25, 2019, 7:44 PM UTC

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 microservices are never combined together, they are essentially monoliths under a cooler name.

This assertion completely misses the whole point of microservices: have highly specialized services that have a single and very limited responsibility, which clients can query independently and enable systems to be scaled (even horizontally) on their performance bottlenecks alone.

Describing a microservice architecture as a bunch of monoliths is simply missing the whole point.

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

#92

Post by geezerjay » Mon, Feb 25, 2019, 7:51 PM UTC

aedron wrote: post #87

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

> Each microservice maintains its own database, with a model that is tailored to its own domain. This is called a projection

In DDD land this is referred to as bounded context.

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

#93

Post by tatersolid » Fri, Mar 01, 2019, 3:11 AM UTC

HelloNurse wrote: post #80

gcufhg wrote: post #23

Earlier quoted context omitted.

You could build a separate ReportService which replicates only the data that's needed for a report in RDBMS.

With a sane database design, the Report service can read user details of all users of interest from the user service and ask the Orders service for the orders of each user (a presumably efficient query), without replicating data.

So you’re guaranteeing O(n^2) runtime?

Relational DBs are really just fantastic at high-performance sorts, merges, and joins. Why do you want to pay the continual ongoing cost of replicating that poorly and inefficiently in your application logic? For each microservice that refers to another in some way?