Batch vs Real-Time vs Event-Stream Processing

Batch, real time and an event stream are three arrangements for when work gets done. Batch collects items and processes them on a schedule. Real time handles each item while somebody waits for the result. An event stream reacts to each item the moment it exists, with nobody waiting. The choice follows from who is waiting and how fast the response can be, never from which of the three sounds most modern.

Almost every argument about these three is really an argument about speed, held by people who have not asked what the speed buys. The speed of a system is not the speed of an outcome. A system can know something in one second and still deliver nothing to anybody for a day, and where that is true, the second was bought and thrown away. The arrangement sets how quickly a system can know something; it does not set how quickly anybody acts on it, and only the second of those two is felt by a customer or by a controller. Every figure that follows belongs to one deployment at Sumeru Bank Limited, an invented lender.

What is the actual difference between the three arrangements?

A household runs all three without naming them. The electricity bill, the school fee and the milk account get settled on the first Sunday of the month, together, in one sitting: that is batch processingCollecting items and processing them together on a schedule, rather than one at a time as each arrives.. The vegetable seller weighs the bag while the customer stands there with a hand out, and nobody leaves until the number is on the scale: that is real-time processingHandling each item as it arrives, while somebody waits for the result before anything else can happen.. The doorbell rings, somebody gets up and opens it, and nothing was scheduled and nobody was queueing: that is event-stream processingReacting to each item as an event the moment it exists, with no schedule and nobody waiting on the answer..

Now the awkward part, and it is the part most comparisons skip. Two of the three do their work at the same moment, so timing alone cannot separate all three. Real time and an event stream both act the instant the item exists. Timing does not separate them at all. The separating question is whether anything is waiting for the answer. The vegetable seller has a customer standing there; the doorbell does not. So the three do not sit on one line running from slow to fast. The three arrangements sit on two questions, and it takes both questions to place all three.

Ask when the work happens, and ask whether anything is waiting for the answer. Batch is scheduled with nobody waiting. Real time is immediate with somebody waiting. An event stream is immediate with nobody waiting. A fourth combination is left over, scheduled with somebody waiting. Nobody designs that combination on purpose and every institution has it anyway. Scheduled work with a person waiting on it is the definition of an unhappy customer, and in this chain it is the exception path: a file that stops still takes 2 working days while the applicant sits there with nothing to refresh.

Notice what that map does to the word fast. Arrangement 1 and arrangement 3 are equally quick at the moment of acting. Because one of them has a person on the other end of the wait and the other does not, the two are built differently, staffed differently and fail differently. A waiting party is not a speed requirement; it is a design constraint that reaches into everything, including what has to happen when the step is unavailable for ten minutes.

What does a schedule buy, and what does it cost?

A schedule buys two things and pays for them with one. The first thing it buys is cheapness per item. Every run carries a fixed cost that does not care how many items are in it: something has to start, connect, pull both sides of the comparison, write a log and stop. Put 430 items through one run and they share that cost 430 ways. Put 18 items through it and eighteen items carry the whole of it. The second thing a schedule buys is context, quieter and more valuable than it sounds. A run held until the day is closed sees every one of that day's items together.

A schedule pays with waiting. The item that arrives first in a run waits the entire run interval before anything happens to it, and that waiting is the only currency a schedule has. Every improvement in cost per item is bought with somebody or something waiting longer, and every reduction in waiting is bought with more runs, each carrying its own fixed cost again. The batch trade is that and nothing more. It cannot be engineered away, and the only real decision is where to put the waiting so that nothing downstream is standing in it.

Read the two crossing curves as one sentence. Moving this reconciliation from one run a day to four runs a day would take the longest wait from 24 hours down to 6, and it would put about 108 items in each run instead of 430, so each item would carry four times the fixed cost of a run. Nothing about that trade is unusual or avoidable. Whether the trade is a good one is entirely a question about the 6 hours, and specifically about whether anything downstream can use them.

What changes the moment somebody is waiting?

Everything downstream of the word available. When a customer is on a handset with a half-finished application, the reading step cannot answer at its convenience: it answers now or the applicant is looking at a spinning circle. In this chain that path returns a decision in about 4 minutes, median, and 5,590 of the month's 8,600 files went down it without a person touching them, being 65.0 per cent. Four minutes is not fast because somebody wanted a fast number. The four minutes exists because a person is sitting there, and for no other reason.

A waiting party changes three design questions that a scheduled run never has to answer. The first is what to show while the work is happening. The second is what happens when the step is unavailable, given that it cannot simply be tried again tomorrow. The third is what capacity stands by for the busiest ten minutes of the busiest day, rather than for the average. Real time is expensive not because the work is harder but because the work has to be available at the moment somebody asks for it, and availability is bought in idle capacity.

A bank branch shows this. A counter that serves people as they walk up has to be staffed through the quiet hour as well as the rush, and staffing it for the average means a queue out of the door twice a day. The back office upstairs works a pile that arrived overnight. The back office can be staffed for the average and simply start earlier when the pile is bigger. Same institution, same people, completely different staffing arithmetic, and the whole of the difference is that one of them has somebody standing in front of it.

What does it mean to react to each item as it arrives?

An event stream sits where the item is worth acting on the instant it exists and nobody is waiting for the answer. The fraud monitoring on the servicing book at this bank is arrangement 3: each transaction arrives, the rules look at it, and about 18,000 alerts come out in a month. Nobody is queueing behind any single transaction. The reason for acting immediately is not politeness to a waiting person; it is that the value of acting decays. The money moves, so a transaction pattern worth catching is worth catching now.

Two things get harder here and both are worth knowing before anybody proposes an event stream. The first is order. Items in a stream do not always arrive in the sequence they happened, and a step that acts on each item as it lands can act on a later item before an earlier one. The second is correction. An event stream acts before the picture is complete, so it will sometimes act on an item that a later message corrects, and the step has to be able to unwind what it did. A batch that runs after the day is closed never meets either problem. Missing both is a genuine advantage of a schedule and is almost never counted as one.

The household doorbell has the same two failures. Somebody rings, the door opens, and the delivery turns out to have been meant for the flat upstairs: the household acted on an item that was not its own. Or two people ring within a minute and the second one is opened to first: the household acted out of order. By Sunday the picture is complete, so neither happens to the pile of post sorted that morning.

How does each of the three fail, and would the failure be noticed?

LatencyThe time between something happening and a system knowing about it, measured in elapsed clock time. is where these three get compared. Because the failures look nothing alike and land on different people, failure is where they should be compared. Take them in order.

A batch fails in bulk. The run does not start, or it starts and dies halfway, and the whole day of items is late together. One fault, one line in a log, and 430 items sitting where nobody has looked at them. The failure is quiet at 3 in the morning and loud at 9, and the recovery is a rerun. Every batch therefore needs to be safe to run twice. A real-time step fails one person at a time, in public. The applicant sees it. A real-time failure is smaller and far more visible, and it is the only one of the three that generates a phone call within a minute. An event stream fails in the most awkward way of the three: it keeps running and acts on the wrong thing, or acts twice on the right thing, and nothing anywhere reports an error at all.

The silent failure of a stream deserves its own sentence. A bank that runs an event stream still runs a reconciliation for exactly that reason. A scheduled reconciliation compares two records that were built separately, and comparing two separately built records is the only way a silent failure is ever found. An event stream, the fastest of the three, depends on a scheduled batch, the slowest, to tell it that it went wrong. Any proposal to replace every batch with a stream should be asked what would have caught the stream.

What does each one cost to build, and what does each cost to run?

Sumeru Bank never split its costs by arrangement. The whole chain cost Rs 2,40,00,000 to build once and Rs 65,00,000 a year to run, and not one line of that was ever attributed to the reading step being immediate rather than scheduled. A cost that cannot be attributed is a cost that cannot be argued about, and that is why almost every argument over arrangements is fought on qualities instead of on rupees. The cost driver of each arrangement can be named instead, and the cost driver is what actually moves the total.

One costed figure does exist, and it carries the rest of the argument, so it is worth stating once and cleanly. Moving the disbursal reconciliation from arrangement 2 to arrangement 3 was estimated at 40 working daysSeven hours at this bank, being 420 minutes, which is the unit every elapsed figure converts into. of build. A working day at this bank is 7 hours, so 40 working days is 280 hours. Those 280 hours are the only number anybody attached to any of this, and the proposal that carried them was turned down.

Where does one chain put each of the three?

One chain runs all three at the same time. Nothing else about arrangements is as useful to know. The arrangement is a property of the step, not of the system, and any statement of the form this is a real-time bank is a statement about nothing. Take the three steps side by side.

Read down the right-hand side of that picture and one thing stands out. The three steps do not differ in how hard the work is. The three steps differ in who is on the other end of the work. An applicant is on the other end of the first, so it has to be immediate. A controller is on the other end of the second, and a controller works a list once a day. A moving balance is on the other end of the third, and money does not wait for a schedule.

Which four questions actually choose the arrangement?

Four questions, asked in this order, and in most cases the fourth is never reached. The first is who is waiting. Who is waiting separates arrangement 1 from the other two, and it is usually answered in a sentence. The second is how fast the response can be, and it settles more cases on its own than the other three together. The third is what a wrong or missing item costs while it sits. The cost of sitting is what makes fraud monitoring a stream and payroll a batch, even though neither has anybody waiting. The fourth is what the arrangement costs to build and to run, and it decides only the cases the first three left open.

Question 2 is worth saying slowly, and it is not a question about the system at all. Question 2 asks what happens after the system speaks. If the answer is that a person reads a list once a working day, then question 2 has an answer, that answer is once a working day, and every arrangement quicker than that is producing an improvement that stops at the edge of the machine.

Why is the response time the one to ask about, and not the detection time?

Two clocks run on every item and people routinely quote the wrong one. Detection timeHow long an item can sit before the system notices that it needs attention. is how long an item can sit before the system notices it needs attention. Response timeHow long an item can sit before a person or another system actually does something about it. is how long it can sit before a person or another system does something about it. Only the second clock is felt by anybody, and the two move completely independently.

A cardholder already lives this. The bank sends a message the instant a card is used. Detection is measured in seconds. If the cardholder looks at the phone once in the evening, the response is measured in hours, and moving the message from three seconds to one second changes nothing whatsoever about when the use is discovered. The message is not useless; its speed simply stopped mattering the moment it outran the person receiving it. A detection clock that outruns the response clock buys nothing, and the arithmetic says so whatever anybody's opinion.

At this bank the same shape appears in the reconciliation. The daily run compares 430 disbursal items against the core ledger, 421 match on their own, being 97.9 per cent, and 9 breakAn item the two records disagree about, which a person has to investigate and clear before it can be closed.: 5 timing, 3 amount and 1 duplicate reference, and 5 plus 3 plus 1 is 9. One person works those 9 breaks, once a working day, at 25 minutes each, and 9 lots of 25 minutes is 225 minutes. Because the list is worked once a working day, the longest a break can sit before a person looks at it is 24 hours, and no change to the detection arrangement moves that figure at all.

Two units are running here and mixing them is the commonest mistake in this whole subject. The 24 hours is elapsed clock time, wall to wall, including the night. The working day is 7 hours of somebody actually at a desk. A run once every 24 elapsed hours and a desk that works 7 hours inside that window are perfectly consistent, and the reason the response bar sits at 24 hours rather than at 7 is that a break arriving just after today's list was worked waits for tomorrow's.

Turn the assumption off and the picture reverses completely. Reversing it is the honest half of the argument. If somebody were on duty to act within 15 minutes of a break appearing, then running continuously would take the time before anybody acts from more than a day down to about a quarter of an hour, and the 280 hours of build would be buying something real. Detection speed bought nothing at this bank, and not because batch is fine or streams are hype. The reason is narrower: this deployment answers its breaks once a working day. Change that and the arithmetic changes with it.

What happened when this bank costed the change and turned it down?

The proposal was straightforward and it was not a silly one. Move the disbursal reconciliation from arrangement 2 to arrangement 3. Instead of a run once every 24 hours, the comparison would happen as each disbursal instruction lands. Build cost, 40 working days, being 280 hours. Benefit as written, the longest a break can go undetected falls from up to 24 hours to under a minute. Scored against its stated benefit, it looked excellent, and it went into the pack looking excellent.

How can a real latency requirement be told apart from a preference?

Ask what acts on the output, and how fast that thing can act. Those two questions are the whole test, and asking them takes about a minute. A requirement with a waiting party behind it survives the question: the applicant on the handset is waiting, cannot be asked to come back tomorrow, and abandons the form if the answer takes long enough, so the four minutes is a requirement. A requirement with nothing behind it collapses at once: nobody could name what would move faster if a break were detected in one minute rather than in a day.

Two habits make this easier. The first is to insist that every stated latency figure comes with the name of the thing waiting on it, in the same sentence. Under a minute is a preference; under a minute because the person on duty is paged and acts within fifteen is a requirement. A latency number that cannot name what is waiting on it is a preference wearing a number, and it is the single easiest thing to catch in a proposal. The second habit is to ask what the improvement would do to the failure list. Every arrangement swaps one set of failures for another rather than removing them.

How would somebody use this on a proposal handed to them tomorrow?

A controller in an operations team reads it as a staffing question before a technology question. If the break list is worked once a day, the arrangement is settled and the only interesting conversation is whether the list should be worked twice. Ismail Sheikh, who runs the exception desk at this bank, has the same reflex about his own queue: a change that makes work arrive faster without making anybody available to do it just moves the waiting from one place to another and calls it an improvement.

A credit or risk reviewer reads it as a failure question. Neelima Rao, who did the independent validation of this chain and built none of it, would ask what each arrangement fails at and what would catch that failure. Asking both is how the silent double action of a stream gets onto a risk register instead of into a footnote. An analyst outside the institution reads it as a cost question, and the useful move there is to notice that a bank quoting a detection figure has said nothing at all about its turnaround until it also states when a person acts.

And a household reads it as a settings question on a handset. Turning on an instant alert for every card transaction is detection. Deciding to look at the alerts, and when, is response. The alert that is never opened until Sunday is a daily batch wearing the clothes of an event stream, and the person who set it up is the one who chose that, not the bank.

Sumeru Bank Limited, Ismail Sheikh and Neelima Rao are invented.
Educational material. Not advice on any investment, tax, budget or market position.