One Big Message?

This is the scenario: periodically, one component is going to look for objects that satisfy some criteria and tell the others. For example, perhaps it is the accounts whose billing anniversary is today. A bunch of other components are interested in these accounts, and so we’re going to send a message out that they can subscribe to and be notified of billing anniversaries. Clearly the initiating component is going to do a single query and get back a big list of accounts; should it send out a single big message, or many small ones?

Ordinarily, when one component is talking to another, I like to see as much go into each message as possible. This was a lesson we learned back in the days of CORBA (which I realize may not be completely over everywhere) when, based on some particularly optimistic advice from authors who had apparently never actually built more than sample code, everyone I worked with was composing interfaces for inter-process communication that exposed miriad small methods. The key to killing performance of distributed systems, it turns out, is to make communication synchronous and chatty so that the communication overhead dominates the payload. Maybe this is what killed CORBA for so many people; I have no doubt their early experiences with performance sewed some initial seeds of doubt.

However, in this case, we don’t have the same scenario. First of all, we’re talking about asynchronous communication. So, while we would add communication overhead by going with multiple small messages, it’s overhead that will only affect total processing resources, and not latency of individual requests. On the other hand, there is quite a bit to be gained from using multiple small messages —

  • we can route and filter the individual messages based on their contents.
  • we can scale the message processing by “simply” adding more sinks.
  • we can be much less clever about interrupted processing: the sink consumes each message in a transaction, and so, a failed transaction will be restarted automatically (perhaps by another recipient)
  • the constant-size messages mean that the sink does not have to scale. So, if we have a simple in-memory reader for the message that works for 20 accounts today, the same reader will work tomorrow when we have 20k accounts.

It’s a small question in the grand scheme of enterprise architecture, but all these small things add up.

Perhaps the next question is: how small is too small?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: