Streaming vs Batch Decision
Choosing between continuous and periodic processing based on the decision latency the business actually requires, not on the appeal of real-time.
The question to force into the open is: what decision changes because the data is fresher? If the answer is that a person looks at a dashboard each morning, batch is correct and streaming is an expensive preference. If the answer is that a transaction is blocked, a price changes, a device is throttled, or an alert fires, then latency has a value and streaming earns its complexity.
Streaming costs more than its infrastructure bill. It is harder to test, harder to reason about, harder to correct after a defect, and it requires the team to understand event time, watermarks, state and ordering. That capability requirement is a real constraint in most organisations and is usually omitted from the decision.
Micro-batch deserves more consideration than it gets: processing every one to five minutes captures most of the practical benefit of streaming for a large class of use cases, with dramatically simpler operations, straightforward reprocessing and conventional testing.
The pattern that works well in practice is a hybrid drawn along consequence lines — streaming for the narrow set of decisions that must be immediate, batch for the reporting and analytics that follow, with both derived from the same source of truth so the numbers reconcile. What fails is building everything streaming for uniformity, and then discovering that correcting a defect requires replaying eighteen months through a stateful job nobody who wrote it still works here.