I have a design question. I have an app(let's call it app A) gathering statistics from a system, by regularly polling each component in the system. I have a second app(app B) which is supposed to make some decisions and enforce them into the same system, that app B is gathering statistics from. For the decision process, app B needs some info from the statistics gathered by app A. So, at certain moments in time(this would be 10-100s times per second) app B makes a request to app A to get some info(i.e. some up to date statistics about the system). What's the best solution to implement this exchange of info from app A to app B? I was thinking of 2 solutions:1) an RPC-style solution, using a message queue (RabbitMQ) 2) a database-based solution, have a table where app A publishes the most up to date info and app B reads it whenever needed. Please provide some insight on whether any of these two would make a good solution or not. Any other suggestions are welcome. Thanks!
Consider reversing the flow of information. Have App A tell App B when something changes, possibly via a message/event using a message queue. App B can then keep it's own highly-available version of App A's data and query it quickly and efficiently without crossing the wire or process boundaries. This highly-available store could simply be in-memory, or some sort of high-performance key-value store.