Batch processing
Process data in fixed windows (hourly, daily). Simple to implement, easy to reprocess, and cost-efficient. Latency equals the batch interval — acceptable for daily reports, not for fraud detection.
Streaming processing
Process events as they arrive. Low latency (sub-second to seconds). More complex: state management, exactly-once semantics, late-arriving event handling. Use when the business needs data in near real-time.
Lambda architecture
Run both: a batch layer for accurate historical data and a speed layer for low-latency approximations. Views merge both. Complex to maintain — two codebases for the same logic.
Kappa architecture
Streaming only. Historical reprocessing is done by replaying the event log from the beginning (Kafka's retention makes this practical). One codebase. Preferred when the streaming framework (Flink, Spark Streaming) can handle historical reprocessing at adequate speed.
Recommendation
Start with batch. Add streaming only when latency requirements cannot be met otherwise. The operational complexity of streaming is real.