We are working on a project which interacts with multiple third party systems and they need each other's data to function. Now, for some data which needs to be in sync in multiple systems, we are planning to introduce event based architecture where if the data is created/updated in one system, it will publish an event and the other's will subscribe to those events.

The problem(?) I have is, these are third party systems. One is deployed to Microsoft Azure, other is deployed to AWS and some other is deployed to their own data center etc. In short their is no certainly what kind of infrastructure the third party systems might be using.

Currently, they communicate with each other over HTTP.

The question is - while introducing event driven architecture, should my system directly consume from a queue which is in third party infrastructure? OR let them write the consumer as well which will continue to communicate with my system over HTTP?

  • Do the easier one, and if it turns out to be the wrong decision you can fix it then when you have more information and experience.
    – jhyot
    Commented Jun 5, 2018 at 18:06
  • That's true. However, I would like to hear more from other's who have experienced such dilemma before. Appreciate your answer. :) Commented Jun 5, 2018 at 18:08
  • Sounds like your team is building an ESB, which is pretty common. The whole benefit of such a thing is that it is integrated into applications from a diverse field of third parties; that is sort of the point.
    – John Wu
    Commented Jun 6, 2018 at 2:45

1 Answer 1


I'm not clear on the two options. It appears you're saying you could read directly from a queue, or let a third party write something that reads from the queue and pushes the message to you via an api endpoint.

If this is the choice, I would much prefer the queue. Queues are designed to be tolerant of consumer downtime so if your consumer is down for maintenance the messages just wait until you're back up. If your vendor writes a queue reader and pushes to your endpoint, they may not be as tolerant and you could lose messages.

In fact, if the queue they have internally is RabbitMQ or something similar, these all support HTTP push notifications so the end result is an HTTP call to your system anyway.

As for the different service providers, there's not much difference reading from a queue in AWS, Azure, or on premises. The syntax to pull a message off a queue is going to be slightly different for each implementation, but the basic ideas are the same.

  • I have added my comment as an answer as it was too long to be a comment. Let me know what you think. Commented Jun 7, 2018 at 3:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.