Real-Time vs Batch Processing

Data processing broadly falls into two modes: batch and real-time. Batch processing handles data in large chunks on a schedule - hourly, daily, or weekly. Real-time (or stream) processing handles data continuously as it arrives, typically with latencies measured in milliseconds to seconds. Most AI systems use both. Training is almost always batch - you assemble a large dataset and process it in one go. But serving predictions often requires real-time data. A fraud detection system needs to consider the transaction happening right now, not just historical patterns. A recommendation engine should reflect what a user clicked five seconds ago, not yesterday. The choice between real-time and batch involves trade-offs around cost, complexity, and freshness. Real-time processing requires streaming infrastructure like Apache Kafka or Amazon Kinesis, adds operational complexity, and typically costs more per record processed. Batch processing is simpler and cheaper but means your data is always somewhat stale. Many organisations adopt a "lambda architecture" or similar hybrid approach, running batch pipelines for thoroughness and streaming pipelines for freshness, then combining the results. The right balance depends on your use case - a product recommendation that's a few hours old is usually fine, but a fraud alert that's a few hours late is useless.