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

11–20 of 121 posts

Re: Microservices should form a polytree

#11

Post by nightpool »

Neywiny wrote: post #4
vedhant wrote: post #3

This actually makes a lot of sense. I have one question though. Why is having 2 microservices depend on a single service a problem?

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 responsibilities / scaling needs / etc.

And then N4 is a shared utility service that's responsible for e.g. performance tracing or logging or something similar. To make the dependency "harder", we could consider that it's a shared service responsible for authentication and authorization. So it's clear why many root services are dependent on it—they need to make individual authorization decisions.

How would you refactor this to remove an undirected dependency loop?

Re: Microservices should form a polytree

#13

Post by rhelz »

buster wrote: post #10

Isn't it the same wisdom as to avoid cyclic dependencies?

It is not only that. An acyclic graph can be non-planar, which means that as you add more nodes, the number of edges can grow as O(n^2).

A polytree is a planar graph, and the number of edges must grow linearly with the number of edges.

Re: Microservices should form a polytree

#14

Post by didibus »

I might have a different take. I think microservices should each be independent such that it really doesn't matter how they end up being connected.

Think more actors/processes in a distributed actor/csp concurrent setup.

Their interface should therefore be hardened and not break constantly, and they shouldn't each need deep knowledge of the intricate details of each other.

Also for many system designs, you would explicitly want a different topology, so you really shouldn't restrict yourself mentally with this advice.

Re: Microservices should form a polytree

#15

Post by suspended_state »

Neywiny wrote: post #4
vedhant wrote: post #3

This actually makes a lot of sense. I have one question though. Why is having 2 microservices depend on a single service a problem?

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 think it does indeed make a lot of sense in the particular example given.

But what if we add 2 extra nodes: n5 dependent on n2 alone, and n6 dependent on n3 alone? Should we keep n2 and n3 separate and split n4, or should we merge n2 and n3 and keep n4, or should we keep the topology as it is?

The same sort of problem arises in a class inheritance graph: it would make sense to merge classes n2 and n3 if n4 is the only class inheriting from it, but if you add more nodes, then the simplification might not be possible anymore.

Re: Microservices should form a polytree

#17

Post by throwaway894345 »

didibus wrote: post #14

I might have a different take. I think microservices should each be independent such that it really doesn't matter how they end up being connected. Think more actors/processes in a distributed actor/csp concurrent setup. Their interface should therefore be hardened and not break constantly, and they shouldn't each need deep knowledge of the intricate details of each other. Also for many system designs, you would expl…

I agree with this, and also I’m confused by the article’s argument—wouldn’t this apply equally to components within a monolith? Or is the idea that—within a monolith—all failures in any component can bring down the entire system anyway?

Re: Microservices should form a polytree

#18

Post by Perz1val »

Rule #2 sounds dumb. If there can't be a single source of truth, for let's say permission checking, that multiple other services relay on, how would you solve that? Replicate it everywhere? Or do you allow for a new business requirement to cause massive refactors to just create a new root in your fancy graph?

Re: Microservices should form a polytree

#20

Post by throwaway894345 »

Neywiny wrote: post #4
vedhant wrote: post #3

This actually makes a lot of sense. I have one question though. Why is having 2 microservices depend on a single service a problem?

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…

Most components need to depend on an auth service, right? I don’t think that means it’s all necessarily one service (does all of Google Cloud Platform or AWS need to be a single service)?
Post reply on HN