01.06 · Concept
Batch, Stream, and Serving Boundaries
Decide whether a data use case should be implemented with batch processing, streaming processing, online serving, or a hybrid architecture.
Batch, streaming, and online serving solve different data boundary problems: recomputation over complete history, continuous reaction to new events, and fast request-time access. The right choice depends on freshness, correctness, read latency, late data behaviour, and operating cost. Many production designs combine them rather than choosing only one.
What this lesson answers
- when should I use batch instead of streaming
- how is online serving different from streaming
- how to choose batch streaming or serving architecture
Notes
Batch, streaming, and serving are boundaries in a data architecture, not just tool categories. Batch processing is best when the business can tolerate data being minutes, hours, or days old and when correctness, completeness, and cost efficiency matter more than immediate reaction. Typical examples include daily financial reporting, model training datasets, backfills, historical aggregations, and compliance exports.
Common questions
- When is batch processing the right choice?
- Use batch when the business can tolerate stale data and values correctness, completeness, repeatability, and cost control more than instant reaction. It fits reporting, compliance extracts, training data, historical aggregation, and backfills. If a scheduled job satisfies the freshness requirement, batch is usually the simplest reliable option.
- When do I need streaming rather than batch?
- Use streaming when each event has value soon after it happens, or when the system must detect evolving patterns across recent events. Fraud checks, operational alerts, inventory movements, and live activity metrics are typical cases. Streaming adds operational complexity, so it should be justified by a real freshness or reaction requirement.
- What is the role of an online serving layer?
- Online serving exists to answer live application requests quickly and reliably. It is not mainly where heavy data preparation should happen. A serving layer usually reads from data already shaped by batch jobs, streaming pipelines, or both, then exposes it to APIs, dashboards, feature lookups, or personalisation systems.