Comment by lacker | Hacker News Reader

Comment by lacker | Hacker News Reader

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 to log that too. And you might want to log whenever any chargeback occurs.

Okay, but now it is no longer a "polytree". You have a "triangle" of dependencies. Payment -> Push, Push -> Logs, Payment -> Logs.

These all just seem really basic, natural examples though. I don't even like microservices, but they make sense when you're essentially just wrapping an external API like push notifications or payments, or a single-purpose datastore like you often have for logging. Is it really a problem if a whole bunch of things depend on your logging microservice? That seems fine to me.

Is your example really a "triangle" though? If you have a broker/queue, and your services just push messages into the ether, there's no actual dependency going on between these services.

Nothing should really depend on your logging service. They should push messages onto a bus and forget about them... ie. aren't even aware of the logging service's existence.

That example is still an undirected cycle so not a polytree and so, by the reasoning of the author of tfa not kosher for reasons they don’t really explain.

Honestly I think the author learned a bit of graph theory, thought polytrees are interesting and then here we are debating the resulting shower thought that has been turned into a blog post.

That was my impression as well. There's pretty much no argument for why a DAG is worse than a polytree.

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.

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)

In my experience this is best done as an out of band flow in the background eg one of the zillion services that collect and aggregate logs.

The issue is that one of the services is the events hub for the rest to remain in loose coupling (observer pattern).

The criticality of Kafka or any event queue/streams is that all depend on it like fish on having the ocean there. But between fishes, they can stay acyclicly dependent.

Reply on news.ycombinator.com