Event Driven Apps using TOPICs| Missed or Duplicate Events
Missed Forever or Delivered again …
Event Driven Apps that runs on Messages, would like to ensure that each and every message gets delivered; and should only get delivered once. Architectural decisions though, can sometimes create scenarios that might lead to time-bomb of multiple messages suddenly showing up out of nowhere.
Every Coin has Two faces / हर सिक्के के दो पहलु होते हैं.
In Tech Life, an Architect has to balance both sides of the coins while architecting the solution.
In this writeup — I only go with the case where you as an Architect has decided to use Topic as its Event Delivery Mechanism.
Topic
Choosing Topic as your message delivering framework has many advantages. One of the biggest being scalable architecture. Publisher need not know who the consumer is and how many the consumers are. Consumers can transparently subscribe (or unsubscribe) the topic.
Confused on Topics or Queues?? Refer to my previous Article. Event Driven Apps — Communication Basics.
Consumer can not afford to loose Messages
Topics has a major flaw that messages may be lost if the consumer is offline when the message was published.
Solution:
There is a solution of course — Durable Subscriber. Though it is the customer who has to set it on its end; Publisher of the message would never be aware of any Durable Subscriptions.
Durable Subscriber (are like a dedicated box) that ensures that messages are stored until consumer comes online. When the consumer comes online again / messages are Delivered.
I need Durables…
Developer now realising the importance of Durable — goes for it. It makes its code accept Durable Subscription.
In the DevOps world, if durable is required, it should be created quickly and should start serving immediately.
This does happen — Messaging Servers creates a durable, if it detects that a consumer is asking for Durable. Server will quickly create a Durable (with provided durable name — and server specific parameters); this process is entirely transparent to Developer. This type of durables are called “Dynamic Durables”.
Application stopped loosing messages now. Fast forward few Months …
Why is my App processing old Messages…
If an application using a durable went offline and came back online; with Dynamic Durable, Messaging Server may create a different durable for same application.
Once that happens both the durables will continue receiving / storing messages. One Durable will serve the Receiver/ while other will just store the messages.
If receiver stops again and reconnects — quite possible that receiver may connect back older Durable; and then will receive all the old messages from old dynamic durable.
** Dynamic durables will loose messages — whenever the messaging server reboots.
Whats the Solution:
If receiver has to go for durable to avoids duplicates, receiver should go with Static Durables.
Static durables requires help from Operations Team. Operations Team / Messaging Server Admin would help creating the durables.
Finally
To sum it up:
- Topics are great. Leads to Highly Flexible Architecture. Event Distribution is completely transparent from the Publishers. Event Receivers though will have to be careful — they may loose messages.
- To Avoid loosing messages — Receiver should go for Durables.
- To avoid getting Duplicates, Receiver should go for Static Durables.
If you have any questions / let me know in the chat below.
