Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices should form a polytree

bytesauna.com

Post reply on HN
Print view View original

101–110 of 121 posts

Re: Microservices should form a polytree

#101

Post by matt_kantor »

nightpool wrote: post #11
Neywiny wrote: post #4

Earlier quoted context omitted.

The explanation given makes sense. If they're operating on the same data, especially if the result goes to the same consumer, are they really different services? On the other hand, if the shared service provides different data to each, is it really one microservice or has it started to become a tad monolithic in that it's one service performing multiple functions? I like that the author provides both solutions: join…

I don't understand this. Can you help explain it with a more practical example? Say that N1 (the root service) is a GraphQL API layer or something. And then N2 and N3 are different services feeding different parts of that API—using Linear as my example, say we have a different service for ticket management and one for AI agent management (e.g. Copilot integration). These are clearly different services with different…

I think this philosophy only reasonably applies behind the public-facing API gateway. So the GraphQL API server wouldn't be part of the microservice graph that you're trying to make into a polytree (you also wouldn't consider the client-side software to be part of this graph). You can use GraphQL delegation or similar to move more responsibility to the other side of the line.

The only alternative I can think of is to have a zillion separate public-facing API servers on different subdomains, but that sounds like a headache.

Re: Microservices should form a polytree

#102

Post by gpm »

Scubabear68 wrote: post #94
lacker wrote: post #93

At first this sounds cool but I feel like it falls apart with a basic example. Let's say you're running a simple e-commerce site. You have some microservices, like, a payments microservice, a push notifications microservice, and a logging microservice. So what are the dependencies. You might want to send a push notification to a seller when they get a new payment, or if there's a dispute or something. You might want…

I don’t understand why you would have a logging microservice vs just having a library that provides logging that is used wherever you need logging.

Logs need to go somewhere to be collected, viewed, etc. You might outsource that, but if you don't it's a service of it's own (probably actually a collection of microservices, ingestion, a web server to view them, etc)

Re: Microservices should form a polytree

#103

Post by yunwal »

ericmcer wrote: post #95
Scubabear68 wrote: post #94

Earlier quoted context omitted.

I don’t understand why you would have a logging microservice vs just having a library that provides logging that is used wherever you need logging.

Only good reason would be for bulk log searching, but a lot of cloud providers will already capture and aggregate and let you query logs, or there are good third party services that do this. Pretty handy to search a debug_request_id or something and be able to see every log across all services related to a request.

> but a lot of cloud providers will already capture and aggregate and let you query logs

This is just the cloud provider taking the dependency on their logging service for you. It doesn’t change the shape of the graph.

Re: Microservices should form a polytree

#104

Post by joshuamorton »

Alupis wrote: post #100
henryfjordan wrote: post #39

Earlier quoted context omitted.

An AuthN/Z system would probably end looking like counterexample #2, which immediately raised a red flag for me about the article.

There's no particular reason an Auth system must be designed like counterexample #2. There's many ways to design that system and avoid cycles. You can leverage caching of role information - propagated via messages/bus, JWT's with roles baked-in and IDP's you trust, etc. Hitting an Auth service for every request is chaotic and likely a source of issue.

You don't necessarily need to hit the auth service on every request, but every service will ultimately depend on the auth service somewhere in its dependencies.

If you have two separate systems that depend on the auth system, and something depends on both, you have violated the polytree property.

Re: Microservices should form a polytree

#106

Post by Alupis »

joshuamorton wrote: post #104
Alupis wrote: post #100

Earlier quoted context omitted.

There's no particular reason an Auth system must be designed like counterexample #2. There's many ways to design that system and avoid cycles. You can leverage caching of role information - propagated via messages/bus, JWT's with roles baked-in and IDP's you trust, etc. Hitting an Auth service for every request is chaotic and likely a source of issue.

You don't necessarily need to hit the auth service on every request, but every service will ultimately depend on the auth service somewhere in its dependencies. If you have two separate systems that depend on the auth system, and something depends on both, you have violated the polytree property.

You shouldn't depend on the auth service, just subscribe to it's messages and/or trust your IDP's tokens.

This article, in my interpretation, is about hard dependencies, not soft. Each of your services should have their own view of "the world". If they aren't able to auth/auth a request, it's rejected - as it should be, until they have the required information to accept the request (ie. broadcasted role information and/or an acceptable jwt).

Re: Microservices should form a polytree

#107

Post by nitwit005 »

It doesn't seem possible to maintain the property.

Let's say legal tells us we need a way to let a user delete all of their data. All data is directly or indirectly user data, so we need a request to go to all services.

Examine the first polytree example: https://bytesauna.com/trees/polytree.png

The delete request must go to at least n1 and n4, which can pass below in the heirarchy. If we add some deletion service that connects to both, it's no longer a polytree.

I suppose you could redesign your services to maintain the property, but that would be quite the expense.

Re: Microservices should form a polytree

#108

Post by kyralis »

The restriction to a polytree might be useful -- but only with quite a few more caveats. In the general case, this is absurd; having dependencies that are common to modules that are themselves dependencies of some single thing is not inherently wrong.

Now, if that common dependency is vending state in a way that can be out of sync along varying dependency pathways, that can be a recipe for problems. But "dependency" covers a very wide range of actual module relationships. If we move away from microservices and consider this within a single system, the entire premise falls apart when you consider that everything ends up depending a common kernel. That's not an architectural failure; that's just a common dependency. (Process A relies on a print service, which depends on a kernel, along with a network system, which also depends on the kernel. Whoops, no more polytree.)

This is the sort of "simplifying" heuristic that is oversimplified.

Re: Microservices should form a polytree

#109

Post by abernard1 »

kyralis wrote: post #108

The restriction to a polytree might be useful -- but only with quite a few more caveats. In the general case, this is absurd; having dependencies that are common to modules that are themselves dependencies of some single thing is not inherently wrong. Now, if that common dependency is vending state in a way that can be out of sync along varying dependency pathways, that can be a recipe for problems. But "dependency"…

A useful distinction I've made before is that of technical vs business services.

This also mirrors the alignment that arises in tech companies between platform (very useful to be centralized) vs architecture. Platform technologies are useful as pure technology, and therefore horizontally distributable. Whereas big-a Architecture as a central committee died an ignominious death for good reason: product and business decisions require deep knowledge, and therefore architecture is simply a function a product team does.

I am old enough to remember when there were simply "services," and there was an understanding that a service was something a team or business function did, because it mirrored Conway's Law. The root of service is literally "serve." That there was a one-to-one correspondence between a software service and the team serving others was a given.

Microservices were a natural evolution of this. When growth happened, parts of those things improperly in a too-large service were pushed down so they could be used by multiple teams. But the idea of a hierarchy of concerns was always present in plain ol' SOA.

Re: Microservices should form a polytree

#110

Post by belZaah »

For microservice count N > 10, if your interdependence count k > 2.867N − 7.724, you are better off with a monolith. The assertion is based on a complexity metric, that has been correllated with cognitive and financial metrics. This came as an interesting side discovery when writing Kütt, Andres, and Laura Kask. "Measuring Complexity of Legislation. A Systems Engineering Approach." In International Congress on Information and Communication Technology, pp. 75-94. Singapore: Springer Singapore, 2020.
Post reply on HN