Comments URL: https://news.ycombinator.com/item?id=23038500

Points: 1

# Comments: 2

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.

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

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...

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.

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.

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.

At the risk of stating the obvious, at the end of the day, it's the use cases and user stories that matter, and in my experience, these almost always evolve over the life of a project. Designing from the ground up often ends up supporting potential requirements that never become real. As the project grows and matures, it becomes hard to trace whether some capability in a lower layer is critical or unneeded, so the tendency is to keep everything. This can become an albatross.

The virtue of vertical development, is that it's easier to do all the work and only the work that is required.

Theoretically, the flip side is that it's easy to avoid thinking up front about the big picture, and easy to promote stove-piping with all of its disadvantages.

My guess is that either the traditional or the vertical approach involves eventual refactoring, and that the first leads to bloat in unused capability while the second leads to bloat in duplicated capability. But the bloat comes later in the project with the vertical approach. In the early phases of a project, the vertical approach may lead to leaner, more malleable systems, with faster delivery and user interaction.

Bottom line for me, is that vertical development didn't fail (I thought it would), and had some surprising benefits.

This has been done before of course, but I'm not sure I've seen this combination of syntax on an RDB before. It's certainly easier to read and write that a bunch of outer joins.

What would be nice to know is whether this can work on top of an existing PG database, providing easier syntax.

While their last example makes _sense_:

  open_prs := User.

  open_prs := User.