quizotic

Thank you for the pointer to DB fiddle!

Bridgewater is famous for valuing a culture of almost brutal honesty and fierce internecine warring over ideas. It argues this combination is vital to reaching the deep understanding that is critical to the success of its investments. While Bridgewater has experimented with leadership transitions multiple times, changing directions and reversing course seems consistent and faithful to its internal DNA. Life doesn't always go in neat straight lines. Forcing a simple story line isn't always best.

This seems so much more clear to read, with less typing.

Do you do that by memory? Or do you have some text indexing tool that helps?

This is Dan Abadi we're talking about. More importantly, the points he makes are important, clear and true. If that causes heartburn for Vendor A and pride for Vendor B, that's secondary. The primary goal is to help users of distributed database systems understand the kind of trouble they can encounter with anything less than strict serializability.

NB: there are important applications where correctness in specific situations is not paramount. Double-click and ad-serving companies in general are more concerned about speed and throughput and are generally willing to have approximate correctness. Strict serializability isn't a universal value, but it's good to know about when you DO care about the kinds of anomalies Dan illustrates.

Does anyone remember Larry Harris and "Natural" back in the 1980s?

The only problem with singular nouns for table names is that they occasionally conflict with SQL keywords. The canonical example of this is from the TPC-H benchmark which has tables named REGION, NATION, SUPPLIER, CUSTOMER, PART, PARTSUPP, LINEITEM ... AND ORDERS <- plural because ORDER is a SQL keyword.

I like the singular guidance for all the reasons given. I like the consistency guidance. But the real world sometimes gets in the way.

So true. And so deliciously snarky. Confession: I'm guilty of far greater stupidity. I've asked "Ship of Theseus" questions when interviewing candidates for object database companies, and conservation puzzles, like tessellating a chessboard missing diagonal corners with dominoes. Because "Thank goodness I hired coders who can discuss philosophical identity problems". At least people who can reverse a b tree on a whiteboard can code an algorithm.

Don't C++ 20 modules solve this problem?

Do you have any insight into the reason for the unequal access? Is it that poorer or uninsured patients cannot afford non-emergency healthcare? Is it that they are too far away? Is it education/knowledge/social - belief that they shouldn't go to a doctor for "nothing". Are they "too busy".

Also, are there any studies to show that populations in other countries use their medical systems more frequently across the board, or that they use more frequent preventative visits?

You mention the problem with obesity and its co-morbidities. Are there any studies or plots that show health outcomes (lifespan, infant mortality, maternal mortality) as a function of % of population who are obese? I wonder if poor health is linearly correlated with obesity, without regard to healthcare spending...

Agree you need all of these things and more... but if you could do this above the microservice level, as a piece of K8S or whatever the MSA, then you might have an advance over RDBMS.

The result would be the same features/guaranteed you have with current DBMS, but you get independent deployability, elastic scalability, redundant availability, and other advantages of microservices that are missing with traditional DBMS.

If you never need to coordinate two or more microservices, then sure. But that means you're dealing with a monolith. In the original article, you could combine Orders and Users into a single microservice. That would resolve all the issues that are raised ... except that you might want reference the Users in a different context. At that point, you either have to split Users into their own microservice, or duplicate the User information. Either way, you're backed into consistency issues.

Part of the promise of microservice is that they're small modular independent components that you can connect and combine into higher-level services.

If you need to read information and write information to two or more microservices, then you have transaction issues. If you need to relate information across two microservices, you have reference integrity issues. Just comes with the terrain.

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 the Orders/Customers example of the article. Assume the Customers microservice has some notion of identity, and that the Orders microservice contains a "foreign" reference to Customers identity. If the microservices are truly independent and autonomous, then the Customer microservice should be able to change its scheme for Customer identities, or a delete a Customer. But then what happens to the Orders that reference that now old and outdated Customer identity? If changing the Customer microservice breaks the Orders microservice, then what's the point of the separate encapsulation? Traditional shared database systems have ways to deal with this kind of referential integrity. As far as I can tell, this issue is ignored by microservice architectures. As is the larger issue of cross-microservice constraints (of which referential integrity is just one instance).

The thing that really gets my goat is the lack of cross-microservice transaction coordination. In its place, we get all sorts of hand-waving about "eventual consistency" and "compensating transactions". Growl. Eventual consistency has a meaning that's related to distributed/replicated storage and the CAP theorem. Maybe its principles can apply to microservices, but the onus is on the microservice proponents to actually connect those dots. And most importantly, eventual consistency is implemented and supported by the DBMS, not by application developers. The thought that each microservice will independently implement the transactional guarantees of consistency and isolation should fill everyone with dread. That job should belong to the overarching system, not to individual microservices. It's too hard to get right.

So for now, shared database in microservicew is not an anti-pattern. It may be the only workable pattern. When microservice frameworks grow up and offer the capabilities of shared database systems to microservice developers, then we can talk about anti-patterns.

Is there any protection to be had by a corporate shell game? Suppose I put my technology assets in one corporation, my revenue and monetary assets in a 2nd corporation, and my customer facing presence in a 3rd corporation. The patent trolls descend on the customer facing presence, which has no substantial technology or monetary assets. If it goes into bankruptcy, I lose brand, but can restart elsewhere and preserve my tech and monetary assets ?