Batch vs. Event-Driven: The Scheduled Mail Route and the Rush Courier
the fundamental choice between processing data on a schedule and processing it the instant it happens, and why almost every data system ends up choosing one or blending both.
A postal worker runs the scheduled mail route and the rush courier desk out of the same office, showing when to batch data on a schedule and when to react to it the instant it happens.
the fundamental choice between processing data on a schedule and processing it the instant it happens, and why almost every data system ends up choosing one or blending both.
why collecting data and processing it together, on a schedule, remains the right answer for a large share of real workloads.
the workloads where processing data the instant it happens isn't a nice-to-have, but the entire point.
why processing everything together is more efficient per record, while processing one thing at a time is faster per record, and why you can rarely maximize both at once.
how the component that matches a ready package to an available courier maps directly onto message queues and brokers in an event-driven system.
why event-driven systems need a way to safely retry a delivery without accidentally processing the same thing more than once.
how a dispatch desk protects an event-driven system from collapse when packages arrive faster than couriers can handle them.
how running a batch route and a courier desk out of the same post office maps onto lambda architecture, and why it exists at all.
why some post offices eventually drop the scheduled truck altogether and run everything through the courier desk instead.
how a post office decides between an hourly, daily, or weekly truck schedule, and how that maps onto choosing a batch interval.
why an address-change notice arriving after the package it was meant to redirect causes real problems, and how event-driven systems guard against it.
the honest promise a postal service can actually make about delivery, and why most systems settle for at-least-once plus idempotency instead of true exactly-once.
why a postmaster tracking a hundred independent couriers needs a fundamentally different kind of dashboard than one tracking a single nightly truck.
the honest financial comparison between running one scheduled truck route and keeping a fleet of couriers ready around the clock.
how a post office moves from a truck route to a courier system without losing a single piece of mail along the way.
what changes when the thing dispatching the courier isn't a human at the counter, but a model deciding on its own that something needs to move.
how a post office rehearses for chaos before it actually happens, and what that looks like for an event-driven system's test suite.
why a small post office running one street doesn't need a dispatch desk, a broker, and a fleet of on-call couriers just to deliver the mail.
the recurring, specific ways a scheduled route and a courier system each tend to fail, and what an honest failure catalogue looks like for both.
what it might look like for a post office to decide, package by package, whether something belongs on the truck or with a courier, without a human making that call.