Ask a business stakeholder whether they need real-time data and the answer is always yes, because nobody prefers stale information. The useful question is different: what decision does this data drive, and how quickly must it be made? A dashboard reviewed each morning does not need sub-second freshness. A fraud check during a payment does. Most requirements sit closer to the first than the second, and building for the second unnecessarily is expensive in ways that keep costing.
Batch processing is simpler in every dimension that matters operationally. It runs on a schedule, it is trivially re-runnable when something is wrong, it processes a bounded set so you know when it finished, and debugging means looking at one job's inputs and outputs. If a run fails, you fix and re-run. That recoverability is the underrated advantage - streaming systems are much harder to correct after processing something wrong.
Streaming earns its cost when latency genuinely changes the outcome: fraud detection, live inventory across channels, operational alerting, anything a user is waiting on. It brings real complexity in exchange. Events arrive out of order, so you need windowing and a policy for late data. State must be maintained across an unbounded stream. Exactly-once semantics are achievable but require care at every stage, and getting it wrong means double-counting rather than an obvious failure.
Micro-batching sits between them and covers a surprising amount of what people call real-time. A job running every five or fifteen minutes gives freshness that feels immediate to a human looking at a dashboard, with the operational simplicity of batch. When someone asks for real-time reporting, the requirement underneath is usually within this range, and establishing that saves a great deal of engineering.
The cost difference is not only in building. A streaming platform runs continuously and must be operated, monitored and understood at three in the morning by whoever is on call. A batch job that fails is discovered in the morning and re-run. For a small team, that difference in operational burden is often more significant than the difference in implementation effort, and it persists for the life of the system.
Where you do need both - and many organisations do - resist maintaining two implementations of the same business logic. Two pipelines computing the same metric will disagree eventually, and reconciling them becomes permanent work. Better to have the streaming path serve the genuinely latency-sensitive use, and the batch path be authoritative for reporting, with the difference between them documented rather than treated as a defect to chase.
