Architecture Principles: Messaging Systems – Smart End Points, Dumb Pipes

Asynchronous messaging systems are a critical component of many highly scalable and highly available architectures. But, as with any other architectural component, these solutions also need attention to ensure availability and scalability. The solution should scale along one of the scale cube axes, either X, Y or Z. The solution should also both include and enable the principle of fault isolation. Finally, it should scale cost both gracefully and cost effectively while enabling high levels of organizational scale. These requirements bring us to the principle of Smart End Points and Dumb Pipes.

Fast time to market within software development teams is best enabled when we align architectures and organizations such that coordination between teams is reduced (see Conway’s Law and our white paper on durable cross functional product teams). When services within an architecture communicate, especially in the case of one service “publishing” information for the consumption of multiple services, the communication often needs to be modified or “transformed” for the benefit of the consumers. This transformation can happen at the producer, the transport mechanism or the consumer. Transformation by the producer for the sake of the consumer makes little sense, as the producer service and its associated team have low knowledge of the consumer needs and it creates an unnecessary coordination task between producer and consumer. Transformation “in flight” by the service similarly implies a team of engineers who must be both knowledgeable about all producers and consumers and an unnecessary coordination activity. Transformation by the consumer makes most sense, as the consumer has the most knowledge of what they need from the message and eliminates reliance upon and coordination with other teams. The principle of smart end points and dumb pipes then creates the lowest coordination between teams, the highest level of organizational scale and the best time to market option.

To be successful achieving a dumb pipe, we introduce the notion of a pipe contract. Such a contract explains the format of messages produced on and consumed from the pipe. It may indicate that the message will be in a tag delimited format (XML, YAML, etc), abide by certain start and end delimiters, and for the sake of extensibility allow for custom tags for new information or attributes. The contract may also require that consumption not be predicated on strict order of elements (e.g. title is always first) but rather by strict adherence to tag and value regardless of where each tag is in the message.

By ensuring that the pipe remains dumb, the pipe can now scale both more predictably and cost effectively. As no transformation compute happens within the pipe, its sole purpose becomes the delivery of the message conforming to the contract. Large messages do not go through computationally complex transformation, meaning low compute requirements and therefore low cost. The lack of computation also means no odd “spikes” as transforms start to stall delivery and eat up valuable resources. Messages are delivered faster (lower latency). An additional unintended benefit is that because transforms aren’t part of message transit, a type of failure (computational/logical) does not hinder message service availability.

The 2x2 matrix below summarizes the options here, clearly indicating smart end points and dumb pipes as the best choice.

One important callout here is that “streams processing”, which is off-message platform evaluation of message content, is not a violation of the smart end points, dumb pipes concept. The solutions performing streams processing are simply consumers and producers of messages, subscribing to the contract and transport of the pipe.

Summarizing all of the above, the benefits of smart end points and dumb pipes are:

1. Lower cost of messaging infrastructure - pushes the cost of goods sold closer to the producer and consumer. Allows messaging infrastructure to scale by number of messages instead of computational complexity of messages. License cost is reduced as fewer compute nodes are needed for message transit.
2. Organization Scalability – teams aren’t reliant on transforms created by a centralized team.
3. Low Latency – because computation is limited, messages are delivered more quickly and predictably to end consumers.
4. Capacity and scalability of messaging infrastructure – increased significantly as compute is not part of the scale of the platform.
5. Availability of messaging infrastructure – because compute is removed, so is a type of failure. As such, availability increases.

Two critical requirements for achieving smart end points and dumb pipes:

• Message contracts – all messages need to be of defined form. Producers must adhere to that form as must consumers.
• Team behaviors – must assure adherence to contracts.