The publish-subscribe pattern: garbage-collecting old subscriptions

I’ve been studying distributed systems design, in particular the Udi Dahan’s class. He talks about the publish-subscribe pattern as a common pattern in messaging-oriented designs. There’s obviously a clear point in time when subscriptions to a publisher happen. However—and I might be missing something—he spent no time discussing unsubscribes.

So my question is—given a distributed system with components that evolve over time, how do popular implementations of this pattern deal with stale subscriptions? I understand that in a optimal situation, there are points in time when the subscriber explicitly declares that it is no longer interested in messages from a given source (maybe on clean shutdown, maybe on some kind of decommissioning of the component)… but given faulty networks, software and hardware, I can imagine the case where the publisher keeps thinking the subscriber still waits for its messages despite not existing for years, and no-longer-necessary messages clogging the messaging system.

Go to Source
Author: liori

Maintaining Objects Across API Deployment Instances

Maintaining Objects Across API Deployment Instances

I am working on a web application as a hobby and trying to learn some concepts related to cloud development and distributed applications. I am currently targeting an AWS EC2 instance as a deployment environment, and while I don’t currently have plans to deploy the same instance of my API application to many servers, I would like to design my application so that is possible in the future.

I have a search operation that I currently have implemented using a Trie. I am thinking that it would be slow to rebuild the trie every time I need to perform the search operation, so I would like to keep it in memory and insert into it as the search domain grows. I know that if I only wanted to have one server, I could just implement the trie structure as a singleton and dependency inject it. If I do this in a potentially distributed application, though, I would be opening myself up to data consistency issues.
My thought was to implement the trie in another service and deploy it separately and make requests to it (this sounds like micro service concepts, but I have no experience with those). Is this common practice? Is there a better solution for maintaining persistent data structures in this way?

Go to Source
Author: jlat96