In a fulfilment system, what distinguishes a message-driven boundary between packing and shipping from an event-driven one?

## The question behind the question Interviewers asking this are not after two definitions. They want to know whether you can say **who knows whom**, because that is what actually differs, and everything else — flow control, failure handling, how the system evolves — falls out of it. Take packing and shipping in a fulfilment system. - **Message-driven:** packing sends `ShipOrder(orderId, boxSize)` **to shipping's address**. The message expresses intent directed at a particular recipient. One recipient consumes it, from its own intake. - **Event-driven:** packing publishes `OrderPacked(orderId, boxSize, packedAt)` — a **statement of fact about packing itself**, addressed to nobody. Zero, one or ten observers may react. Packing neither knows nor cares. The grammar gives it away. A message is usually an imperative aimed somewhere (*ship this*); an event is usually a past-tense fact about the emitter (*this was packed*). ## What each style couples to what | | Addressed message | Broadcast event | |---|---|---| | who the sender names | a specific recipient | nobody; a topic or stream | | what it carries | intent directed at that recipient | a fact that already happened | | how many consume it | one recipient, at its own intake | zero to many observers | | adding a consumer | changes the sender or its routing | changes nothing in the publisher's code | | who depends on whom | sender depends on the recipient | observers depend on the event's shape | | flow control | a known intake can push back on a known sender | no single party to slow down | | a dead consumer | the sender can notice the silence | invisible to the publisher | Both are asynchronous, and both may run over the same machinery. Neither is defined by having a queue in the picture. The distinction is **addressing**, not transport. ## Why the distinction has teeth Three consequences are worth being able to state: 1. **Direction of change.** Adding a fourth component that wants to know when orders are packed is free in the broadcast style and a change to packing, or to its routing, in the addressed style. That is the strongest argument for publishing facts. 2. **Where responsibility lives.** An addressed message has an owner: exactly one recipient is supposed to act, so failing to act is somebody's fault and can be chased. A broadcast fact has no owner — if every observer ignores it, nothing is technically wrong, which is why work that must happen is badly expressed as an event nobody is obliged to consume. 3. **Flow control needs a recipient.** Demand is signalled by a consumer to a producer, and that requires the producer to know which consumer it is serving. With one addressed recipient, a full intake is a signal that reaches the sender. With a broadcast, there is no single consumer to represent the system's capacity, so a slow observer either falls behind or drags the publisher down to its own rate. ## Both in one system This is not an either-or architecture choice, and treating it as one is a weak answer. A healthy fulfilment system usually does both: picking **directs** work at packing because that work has an owner and must happen exactly once; packing **publishes** that an order was packed so that analytics, the customer-notification component and an internal dashboard can each observe it without packing knowing they exist. A useful test when designing a boundary: *if no component consumed this, would something be broken?* If yes, it is directed work and deserves an addressed recipient. If no — it is information about the past — it is a fact, and publishing it keeps the emitter free of consumers it should not know about. ## What the manifesto actually claims The Reactive Manifesto puts **asynchronous message passing** at the foundation, and that wording is deliberate: the foundational property is that components communicate by sending, not by holding one another's control flow. Broadcast publication is one arrangement built on that foundation, and so is the actor model's addressed mailbox. Answering that message-driven simply means publish-subscribe is the most common error here, and it inverts the relationship: publish-subscribe is a way of arranging message passing, not a synonym for it. ## How a weak answer sounds The weak answers are recognisable. One says the two terms are interchangeable. Another says events are asynchronous and messages are synchronous, which is simply untrue — both are asynchronous, and synchronicity is a different axis. A third defines the difference by the machinery in between, so that any system with a queue becomes message-driven. The answer an interviewer is waiting for names the recipient, or the absence of one, and then draws the consequences for coupling, ownership and flow control.