7

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?

Matthias
  • 1,378
  • 10
  • 23

1 Answers1

8

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.

Gary Russell
  • 166,535
  • 14
  • 146
  • 179
  • With a Queue we need one for every service communication. This is not decoupled enough. We will have about 15 - 20 Microservice. Every service have 2 - 10 Events to publish. And some events are processed by multiple services. So we have to implement A send Event to B, A send Event to C instead A publish Event and B,C Listen for event. – Matthias Apr 21 '15 at 18:12
  • Thanks a lot. I have found VirtualDestinations for ActiveMQ and Fanout for RabbitMQ. Both can solve my problem and should work well with my use case. – Matthias Apr 22 '15 at 09:00