Fescar: High-performance, Java-based, OSS distributed transaction solution | Hacker News Reader

Fescar: High-performance, Java-based, OSS distributed transaction solution

github.com

36 pointsaxiomdata3165 comments

This is cool, but to what extent is the DB-per-Service pattern actually used, or desirable? The alternative of sharing a DB across many services is simpler because you still just rely on transactions in you RDBMS. I get that at some point youll have to shard or go to a multi master setup if thats supported to scale. Im wondering how many companies find themselves in this situation and have chosen a datastore that doesnt support multimaster? Or am I missing some other use case? The wiki links to “supported databases” also doesn’t work... and I dont get what “high performance” means, is there a blog post or benchmark for any reference points?

Db-per-service provides many benefits, albeit with some drawbacks. If you are going to adopt microservices, you've already had to accept most of the drawbacks. Trying to mitigate those drawbacks by consolidating will end up losing much of the benefits of going to a microservice topology. Sagas or compensating transactions are a way to answer this concern without the complexity of a transaction manager.

If each service owns it's datastore, each service can choose the type of datastore that best fits it's use-case.

Each service can be owned and operated independently. Patches, upgrades, schema migrations, etc.

Each services' datastore can be scaled, backed up, restored, encrypted, etc independently all depending on the requirements, scale needs, compliance concerns, etc of a given service.

A badly behaving service can (mostly) not impact other services, where if they all shared a single database a single service could theoretically starve other services.

Yes, the distributed transaction problem is a drawback, but that can be partially mitigated through better definition of each service's bounded context.

I think each of your stated benefits ought to be prefixed with "In a perfect world...". In the real world people don't make perfect decisions about things, and even where they do, requirements often change. Particularly the core decision about where the borders between the services lie and what service is responsible for what. Re-architecting a complex microservice architecture is such an undertaking that instead people will often just live for years with an absurdly mis-shapen design, still having to live with the pain that re-appears any time they need to e.g. make synchronized changes to multiple services.

DB per service scales linearly while the shared database does not.

The top of the readme starts off with a nice simple diagram of a working architecture (traditional monolithic) and as you read further, it balloons into this project + a super complicated set of diagrams with multiple moving pieces.

Reply on news.ycombinator.com