Is a shared database in microservices actually an anti-pattern?
1–10 of 93 posts
Re: Is a shared database in microservices actually an anti-pattern?
#2[deleted]
Re: Is a shared database in microservices actually an anti-pattern?
#3This is more likely to be a problem if you split your services up by noun (Users,Orders) rather than by function (makeOrder, loginService, etc). This isn't bulletproof either but I've seen it helps reduce this occurrence a lot. Pardon the poor examples
Re: Is a shared database in microservices actually an anti-pattern?
#4My take is yes. Shared infrastructure is always a risk. It seems to encourage other bad choices.
Yes, you can design around it. Good discipline around libraries with schemas, and such. These are almost always more code than letting a service own all communication with an infrastructure.
Re: Is a shared database in microservices actually an anti-pattern?
#5Completely 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.
Re: Is a shared database in microservices actually an anti-pattern?
#6"Then it sends request to users service to get missing information about users" What information would an order need to know about the user except for its ID? Shipping address? That could have been stored in the order db. Usually there is an orchestration layer above these services such as graphql, that merges all the data together for presenting to the UI. Somewhere there needs to be a defined contract between service boundaries so that internals can be changed without affecting all dependent systems. The db is not a good place for this contract.
Re: Is a shared database in microservices actually an anti-pattern?
#7Microservices are an anti-pattern.
Re: Is a shared database in microservices actually an anti-pattern?
#8I don't understand the problem. If the report needs order details and user details, and current data isn't available because some piece of the system has a problem, there's going to be no report today regardless of what the database is like and what concerns are separated or not. C'est la vie.
Moreover, the real dependency is from the report to the orders and the users; the article takes for granted that the report is shoehorned into the orders component, but it's clearly arbitrary.
Re: Is a shared database in microservices actually an anti-pattern?
#9Completely 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.
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.
Re: Is a shared database in microservices actually an anti-pattern?
#10This is more likely to be a problem if you split your services up by noun (Users,Orders) rather than by function (makeOrder, loginService, etc). This isn't bulletproof either but I've seen it helps reduce this occurrence a lot. Pardon the poor examples
In other words, data store (domain), behavior (createOrder), and event (orderCreated).
I feel the OPs pain but I’ve built MSAs from DDD principals and it really is a better architecture for complex systems.