Describe the difference between online and batch inference.

Your grasp of serving patterns and infra tradeoffs.
Online uses autoscaling APIs for millisecond-to-second latency; batch uses scheduled compute for minute-to-hour latency.
What's really being asked
This question probes whether you understand that inference is not a single workload but a spectrum of serving patterns. Interviewers want to see if you can reason about latency requirements, resource allocation, cost models, and infrastructure topology rather than just naming two concepts.
The full answer
First, define online inference as synchronous, request-response prediction serving where a client waits for the result, and batch inference as asynchronous, large-scale processing of accumulated inputs without a client waiting. Second, contrast infrastructure: online needs always-on, autoscaling endpoints such as Kubernetes deployments or serverless containers, often with model warm pools, load balancers, and caching layers to keep P99 latency between ten milliseconds and a few seconds; batch needs job schedulers like Airflow, Kubeflow Pipelines, or managed batch services that distribute work across spot or reserved instances, optimizing for throughput over latency with typical runtimes from minutes to hours. Third, discuss resource patterns: online allocates GPU or CPU per concurrent request and must handle traffic spikes, while batch maximizes cluster utilization by processing partitions in parallel and can tolerate preemption. Fourth, mention cost and SLA tradeoffs: online carries higher per-query cost and demands strict availability SLAs, whereas batch leverages cheaper compute and looser timing guarantees.
The mistakes people make
A red flag is claiming that the only difference is speed or that you can simply run the same model container in both modes without changes. Another mistake is ignoring cold-start latency for online serving or suggesting infinite autoscaling without mentioning cost. Candidates also err by omitting data pipeline differences, such as how batch jobs often require ETL preprocessing while online systems need feature stores with low-latency lookups.
What usually comes next
Expect the interviewer to ask how you would handle a model that must serve both real-time and batch, how you choose instance types for GPU-heavy online traffic, or how you would design a fallback when online latency exceeds an SLA. They may also probe monitoring differences, asking what metrics matter for an online endpoint versus a batch job.
A concrete example
Imagine a fraud detection model. Online inference scores each credit card transaction as it happens, requiring an API with P99 latency under fifty milliseconds running on CPU-optimized instances with autoscaling from ten to one hundred pods. Batch inference re-scores the past twenty-four hours of transactions for regulatory reporting, using a nightly Spark or Argo workflow on spot instances that processes ten million rows in thirty minutes with no client waiting for the output.
Interview question
A team must reprocess 30 days of sensor data through an updated model. Which serving pattern and infrastructure choice best fits this workload?
- a.Deploy an autoscaling API endpoint with low-latency feature store lookups to process the backlog synchronously
- b.Use a scheduled workflow on spot instances that partitions data and optimizes for throughput over per-request latencyCorrect
- c.Stream each historical record through a real-time prediction service to maintain strict P99 latency guarantees
- d.Run the job on always-on GPU instances with warm pools to avoid cold starts during the historical reprocessing
Why? this is the answer
This workload is classic batch inference: large historical data processed asynchronously without a client waiting, best served by scheduled workflows on spot instances optimizing throughput. Option A incorrectly applies online feature-store patterns to a backlog, while C and D misuse real-time serving infrastructure and SLAs for an offline job.
Just read this? Test yourself on what you have been reading.
Read the original → inferencesystemsauthority.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on mlops — each one lists the topics its interview covers.
See open roles