Messaging and Event Systems

Once you move past direct client-server transport, you need infrastructure that holds messages in flight. A Message Queue is a buffer: producers add to one end, consumers take from the other, and the queue absorbs bursts so a spike in orders does not crash the service that processes them. The Pub/Sub Pattern broadcasts instead of point-to-point, so one published event reaches every interested subscriber. An Event Bus and a Command Bus apply the same idea inside an application, separating things that announce "this happened" from things that demand "do this."

The way producers and consumers expect a reply matters too. The Request-Response Pattern and Request-Reply Pattern wait for an answer, which feels familiar but reintroduces coupling. Fire-and-Forget gives up the reply entirely for maximum throughput, fine for logging or metrics where a lost message is not a disaster.

Real queues need machinery for the messy cases. A Dead Letter Queue catches messages that keep failing so they do not block everything behind them. Poison Message Handling deals with the one bad message that crashes every consumer that touches it. Priority Queue and Delayed Queue control what gets processed first and what waits. Message Expiration, Message Filters, and the Competing Consumers pattern (many workers pulling from one queue to scale out) round out the day-to-day operations of a working broker.

Event-Driven Architecture is where all of this comes together. Instead of services calling each other in a fixed chain, they emit events and react to events. Adding a new feature often means just subscribing a new consumer to an existing stream, with no change to the producer. This is how large platforms ship independently and scale teams without scaling coordination.

The enterprise integration patterns in this category are the routing and shaping tools that make event-driven systems actually work. Content-Based Routing and the Dynamic Router send each message to the right place based on what is inside it. The Splitter Pattern breaks a big message into pieces, the Aggregator Pattern collects related pieces back into one, and Scatter-Gather sends a request to many services and combines the answers, exactly what a flight search does when it queries dozens of airlines at once. Fan-Out/Fan-In spreads work wide and then pulls results together.

For longer workflows there are stateful coordinators. A Process Manager tracks a multi-step business flow, and a Routing Slip attaches the steps to the message itself. When payloads get large, the Claim Check Pattern stores the bulk elsewhere and passes only a reference, keeping the broker lean. The Normalizer Pattern and Canonical Data Model solve the integration tax of many systems speaking slightly different formats, translating everything into one shared shape. Companies like Uber, Netflix, and any large bank run on exactly these patterns, because at scale the alternative, tightly coupled synchronous calls, simply does not hold up.