Concept
Batch and event-driven are two answers to one question: what starts a message. In a batch model the schedule starts it. A job runs at a set time, queries a segment, and sends the same thing to everyone in it. In an event-driven model the customer starts it. Something they do, a cart addition, a price drop on a saved item, a support ticket closing, emits an event, and that event triggers the flow. The distinction is about the initiator, not the clock speed.
Why it matters
People reduce this to fast versus slow, which hides the real consequence. A batch send can be quick and an event-driven flow can be leisurely. What actually differs is the shape of the stack each one demands. Batch needs a scheduler and a way to query segments, and very little else. Event-driven needs an event backbone that can carry signals in real time and a decision layer that can react to them, which is a materially different architecture. So the choice between them is not a campaign setting you flip per message, it is a decision about what the whole stack is built to do. Teams that treat it as a setting end up with an event-driven ambition sitting on batch foundations, which never quite works.
A simple example
Take an abandoned cart. As a batch job it runs overnight, finds everyone who left something behind that day, and mails them at 6am, by which point some have already bought elsewhere and some abandoned twelve hours ago. As an event-driven flow, the cart event fires the moment it happens, a decision checks whether a nudge still makes sense, and the message goes out while intent is still warm. Same trigger conceptually, but batch relates to it as a daily list and event-driven relates to it as a live signal, and the customer feels the difference immediately.
The architecture view
Who initiates the interaction. On the left the clock starts it, on the right the customer does.
This is why event-native platforms like Braze or Iterable feel structurally different from a traditional ESP that later bolted on triggers. In the event-native design the event backbone is the product, so a single behaviour can start a flow directly, whereas a retrofitted ESP still thinks in lists and treats the trigger as one more scheduled query. So when a vendor claims real-time, the thing to check is whether an individual event can initiate a journey, or whether you are only choosing how often the segment refreshes.
The mistake I often see
The common error is calling batch real-time by shrinking the window. A team moves the nightly job to hourly, then every fifteen minutes, and describes the result as real-time engagement. It is still batch. Nothing in it responds to an individual event; it is just a faster loop over the same segment query, and it carries all the same blind spots, only more often. Real-time is not a small batch. It is a different initiator. Until a customer action can trigger a flow on its own, the architecture is still schedule-led no matter how short the interval, a pattern I have written about at length in the end of batch-and-blast.
Go deeper
The case for why schedule-led marketing is reaching its limit is in The End of Batch-and-Blast. For how the same shift plays out inside one channel, Email Isn’t Dead shows the move from calendar to trigger within the inbox.
This node builds directly on what decisioning is: event-driven only works if something owns the choice the event triggers.