0

I'm new to the microservices field. I'm looking for the right approaches regarding how to deal with the challenge of redundancy of a pus-sub application. Assume my application has has the below constrains:

  1. Real time (very critical)
  2. Heavy load time
  3. Lots of events
  4. Events are metrics (like temperature, stock prices, etc.)

In order to avoid down time, I need probably to instantiate another copy of my application.

Now, if the replication step is right - What should be the strategy for the events replication? Means, if I'm holding 2 instances of the same application, they both publishing the same data.

I can think of 2 approaches:

  • Publisher level
  • Consumer level

Publisher level

Publisher should know that currently he's in isActive=false status. But, I think it's not the right way. Why?

  • Since the publisher may not be aware of its environment. It sounds that it's not a natural part of its responsibility.

  • Who can tell what's the instance isActive status?

Consumer Level

I'll configure something (if possible...) that I'll ignore the same message if it comes again. But it looks me too problematic. Why?

  • That means my queue (Rabbit) gets twice the same messages. If I have very intensive stream of messages that can lead to a performance issue (IMO).

I'm looking for the standard approaches in this challenge. Reading material is welcomed too.

2
  • 1
    Your publisher-level approach looks like an active redundancy or hot-spare approach. You would then need something to monitor the publishers and tell each of them if they should actively publish (isActive=true) or not. – Bart van Ingen Schenau Feb 2 at 14:47
  • @BartvanIngenSchenau Do you mean application should implement isAlive API? Who is responsible for the monitoring? There is a component which this is its responsibility? Thanks! – Roni Feb 2 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.