How do you guarantee exactly-once business effects when a batch scorer retries?
PICTURE THIS: STACK VS QUEUE
Simple meaning
You cannot easily get exactly-once compute, so you make sinks idempotent with a prediction_id and model version as a primary key.
WHY — Batch vs Realtime instead of guessing?
Why interviewers care about Batch vs Realtime:
question about Batch vs Realtime.
trade-offs, and what you would actually do on a MLOps project - not buzzwords.
Name the idea, why it exists, then one short example.
End with when you use it and one common pitfall.
STEPS — What happens step by step?
Before you speak the answer, walk the interviewer through these steps:
- 1You cannot easily get
exactly-once compute, so you make sinks idempotent with a prediction_id and model version as a primary key.
- 2Downstream actions should be
driven by a separate, audited workflow, not by a fire-and-forget score write.
- 3Dead-letter queues capture poison
rows without blocking the job.
- 4Give an example
One tiny concrete case you can say aloud.
- 5Common mistake
What juniors usually get wrong.
- 6Close
When you pick this over the alternative.
EXAMPLE — See it in action
Here's a short line you can speak, broken into clear beats:
Note: Adapt this scaffold to your own project — keep it under 60–90 seconds.
Key takeaway
You cannot easily get exactly-once compute, so you make sinks idempotent with a prediction_id and model version as a primary key. Downstream actions should be driven by a separate, audited workflow, not by a fire-and-forget score write.