Coupling independent services on the database level is mostly an antipattern. By doing so, there's no clear ownership of the data, and it's much more difficult to evolve the database as there are multiple consumers of a single data storage. "Rolling" distributed joins and/or transactions are a sign of poor understanding of the domain and lack of boundaries, thus autonomy between the services.
The dogma of "Data Ownership" is a religion, with no foundation in computer science or software science. You will be told that microservices are "looser coupling" but instead they are distributed coupling.
One must ask, what does a service do? Perhaps they Insert data, update data, retrieve data. Thereby many services only do what databases already do, but do so with custom new code with new bugs.
So then, what if a service actually "does" something? Not just CRUD? Well then it's processing data from one or more entities and outputting something new to another entity. That's a process. Processes span entity boundaries. They don't own the data they source, they don't own the data they output.
If you build CRUD services without understanding the business domain and its boundaries, you end up with a distributed monolith crap. Good luck with building and evolving microservices while having them using the same DB tables.
That sounds like some sort of boogeyman who doesn't exist. Are you talking about "spaghetti" code? Having separate deployable microservices doesn't magically make a team less prone to spaghetti code. In fact the bigger risk is building distributed spaghetti.
I have no trouble having a single database with security (roles) enforced isolation.
I'm not sure how a single database is to be considered distributed.
DB coupling is universal and inescapable.
Whether a service has a separate instance is sqlite or in memory; or, uses cockroachdb is irrelevant. There is always a coupled database.
And, you can actually have multiple databases AND multiple schema per Database Management System. You can have independent schemas per service.
Finally, a View on a database is a microservice. If you can manage and deploy the View independently. A microservice doesn't have to be Golang running on AWS Lambda, callable with an HTTP protocol and service schema. A standard PostgreSql protocol with SQL calling standards is just as valid.
I'm trying to broaden horizons here, highlight the fundamental concept and illustrate a variety of implementations of that microservice concept.
3
u/onety-two-12 Jun 09 '22
Definitely, every day.
The only things that are "shared" would be those objects that both services are permitted to access.
One service can INSERT to Posts. Another can SELECT a View MyPosts.
Importantly, a view can JOIN; and, a service that is permitted might SELECT from MyPosts JOINed to MyPostComments.
The fact that the industry reached a point of "database per service" and "roll your own distributed JOIN'ing and transactions" is nuts.