Consuming messages directly from a queue which belongs to a third party system

Question

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?

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.