Temporal Decoupling
The subject of messaging systems came up in a conversation last week, and some
wheels started turning. I like the idea of messaging systems. It feels
architecturally clean to have all your components abstracted away from each
other, so that each one only sees the message bus, and doesn't give a hoot where
its messages are going to, or coming from. Even more specifically, each
component can choose which messages it wants to get, and not be bothered with
the rest. This again feels tidy.
Not only do messaging systems give you an architectural layer of abstraction,
but you also get the thing that prompted this post: temporal decoupling. If
you have a part of the system that isn't running 24/7, you can either build
'time-locks' into the UI so that it can only be accessed when the system is up,
or you could use a combination of an off-line cache and a store-and-forward
message queue to allow the system to be used in limited fashion even when parts
of it are temporarily down. The cache can be implemented as 'just another
subscriber' to the message queue. Another bonus: adding message consumers is
transparent to message producers, and vice versa. This allows a many-to-many
relationship between components, such that multiple machines can look like one
big virtual one to anything on the other side of the message queue.
Disadvantages? Two network hops (Producer-Queue-Consumer) where before there
was only one. Added development complexity. System administration - now
there's a message queue component to look after as well. Point of failure -
losing your message queue would not be funny. The store-and-forward approach
would not work well for time-critical messages (eg. stock market transactions).
Better to report failure immediately than complete the transaction at some
indeterminate point in the future, when market conditions may be wildly different.
