Microservice Event driven Design with multiple Instances

Question

At the Moment we design and plan to transform our system to a microservice architecture pattern.

To loose coupling we think about an event driven design with an JMS Topic. This looks great. But i don't now how we can solve the problem with multiple instances of a microservice. For failover and load balancing we have n instances of each service. If an event is published to the topic each instance will receive and process that event.

It's possible to handle this with locks and processed states in the data storage. But this solution looks very expensive and every instance has the same work. This is not a load balaning for me.

Is there some good Solution or best practice for this pattern?

Answer 1

Why not use a Queue instead of a Topic? Then your instances will compete for messages rather than all get a copy.

EDIT

rabbitmq might be a better fit for you - publish to a fanout exchange and have any number of queues bound to it, with each queue having any number of competing consumers.

I have also seen JMS topics used where competing clients connect with the same client id. Some (all?) brokers will only allow one such client to consume. The others keep trying to reconnect until the current consumer dies.