In a batch job split into thousands of tasks, the job finishes only when the last task finishes. A single slow machine, a straggler, can double total runtime. The MapReduce paper reported jobs taking 44% longer when backup tasks were disabled.
When a job is near completion, the scheduler launches duplicate copies of the slowest in-progress tasks on other machines. Whichever copy finishes first wins; the other is killed. Hadoop and Spark (spark.speculation) both support it.
Spark, for example, considers a task for speculation once a configurable fraction of tasks in the stage has finished and the task has been running longer than a multiple of the median task duration. Comparing to the median, not the mean, keeps one outlier from distorting the baseline.
The online-serving cousin is sending a second request after the 95th-percentile latency has elapsed, from Google's "The Tail at Scale". Connecting the batch and online versions in one sentence is a strong signal of breadth.
"Job latency is governed by the slowest task, so I'd enable speculative execution for the tail, make tasks idempotent with atomic commits, and treat data skew separately because duplication can't fix it."
Disclosure: I am on the team behind an AI interview assistant (Linkjob AI). These notes are general study material.