Advantage of using a message queue

help
1

When using meteor in a micro service architecture, what are the advantages of using a message queue?

The only advantage I can think of is that messages will survive an application server restart (which actually isn’t necessarily true depending on the architecture of your message queue)

Meteor will queue DDP messages that don’t get delivered and will resend them when it reconnects.

The only disadvantage I can see with this system is that I need to ensure that my messages are idempotent such that if a message is delivered but the ACK is not, a 2nd delivery will not cause an issue.

2

Meteor is not really the tool for micro services. how do you use it in that context?

3

It started because I needed to process some tricky payments - So in some cases my data is in a relational database.
Meteor is used as a thin wrapper, providing RPC’s and Pub / Sub.
My main web app does a server to server connection with a micro service.
The micro service does whatever data manipulation it needs to and publishes data from its own database.
The main web app subscribes to that data, does whatever data manipulation it needs and republishes it to clients.

Some special publication code is used to ensure

  1. Observer reuse when retrieving data from a remote server.
  2. Server to server subscriptions are ended when the last user subscribing to that data disconnects

I could implement all of this in ZeroMQ - with the main advantage being that in theory my micro services will have a smaller memory footprint - but the disadvantage of having to deal with recreating a lot of the functionality that is core to Meteor

1 Like