1

I am currently reading the Microservices Patterns and it says there are mostly two approaches for distributed transactions: two phase commit (2PC) and sagas pattern.

Also, I've heard about currently evolving Distributed SQL (DSQL) tools like CockroachDB, YugabyteDB and YDB, which also support distributed ACID-like transactions via their own low-level db nodes communication.

So the question is, could the latter be applied as an alternative to the former ones?

To illustrate the question, consider the following typical microservices distributed transaction sample. Here we need 2PC or sagas for the red zone coordination.

Microservices 2PC-based transaction sample

What I want would be to completely eliminate the need to develop and support coordination from the business logic side moving it to the general DSQL engine:

Microservices DSQL-based transaction sample

On the one hand, it is clear that such approach somehow breaks the microservice's responsibility segregation principle. Also, as far as I understand, DSQL tools evolved mostly for replication/sharding tasks, and not for the microservices' business logic coordination. On the other hand, it would very much simplify developing and supporting such solutions.

Alexander Bashkirov
  • 63
  • 7

2 Answers2

1

I think it depends what you want to de-couple. With distributed SQL databases, many operations on one database has no impact on the other databases in the same cluster. Like rolling upgrades (vs. monolithic databases were you have to take down all applications sharing the same database), scaling-up, scaling-out.

You can also, within the same cluster, dedicate nodes, to specific applications. Or move them to different regions. And with PostgreSQL compatibility, you can serve many use cases (relational, JSON, key-value, timeseries...) with the same database. For these, you benefit from sharing the same infrastructure, manage service provider, skills... and still de-couple applications.

With the need to de-couple more, like replicating asynchronously, YugabyteDB has xCluster replication. And, there are many levels of coordination possible, in the SQL layer, between the application and the data. The PostgreSQL compatibility comes with triggers, which can call external actions, or Foreign Data Wrappers, which can interact with other databases with a standard API.

So I would say distributed databases bring more possibilities between de-coupling everything (like the choice of the database vendor) and full consolidation that would impact applications.

FranckPachot
  • 414
  • 4
  • 10
  • but in that case you have mddleware, from ibm, sap and others, where it doen't care about which database is where – nbk May 08 '22 at 21:59
1

Having separate databases in a microservice architecture has a few different benefits. Some are obviated by using a distributed database--CockroachDB's resilience, scalability, and dynamic load balancing mean that you generally won't need to worry about tuning your database to the workload of an individual service. But others aren't. Having separate databases forces your services to interact through well-defined APIs, which prevents their logic from becoming tightly coupled, allowing them to develop and update independently. If you're using a shared database to enforce consistency, you're necessarily introducing logical coupling no matter the mechanism, in that you need a shared understanding of what needs to be consistent. This may be unavoidable, in which case the key is really to make the consistency logic explicit and legible, which can be a bit trickier when implemented at the Raft level than in an API.

histocrat
  • 2,291
  • 12
  • 21