In a microservice system I have two services: service1 which has a piece of data and service2 which needs that up to date data from time to time. In order to get the status, service2 calls service 1 through HTTP calls.
service2 --- (get data call) ---> service1
Since service1 changes data status once a couple of hours, I am thinking that in order to lift some load from the network I can replace the constant polling through HTTP calls by a RabbitMQ message being sent from service1 to service2 and that service2 can cache that till the next message is received.
service1 --- (rmq message sent) ---> service2
Considering that the HTTP requests are currently made once per ~10 seconds, and that the data is updated once a few hours, will it be easier from a network point of view to support the new design? In other words, how network intensive is listening on an empty RMQ queue? Is it less intensive than sending an HTTP GET call once each 10 seconds?
how network intensive is listening on an empty RMQ queue? Is it less intensive than sending an HTTP GET call once each 10 seconds?
Yes, it is less "intensive". By "intensive" I assume you mean the bandwidth consumed.
A RabbitMQ consumer will still send heartbeat messages on occasion.
To be honest the biggest improvement will be moving away from a polling architecture to one that is push-based.