Architecture scenarioHard~12 minParallel Workloads / 4 of 12

Interview question

How do cancellation and idempotency change the way you design background jobs?

Cancellation and idempotency in background jobs

Design background jobs that handle cancellation, retries, and duplicate execution without corrupting external state.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A background job should handle cancellation so the worker can shut down cleanly, but it also needs to be safe if it is retried. Idempotency means running the same job more than once should not create duplicate side effects. For example, if a job sends an invoice email or charges a payment, I need a way to know whether that action already happened. Cancellation should not leave the system in an unknown state without a recovery path.

Full answer below

Practice focus

Background processing, retries, duplicate execution, cancellation boundaries, idempotency keys, and safe side effects.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Background jobs fail differently from request/response code. This drill tests whether the candidate thinks about retries, duplicate processing, shutdown, and irreversible side effects.
A background job should handle cancellation so the worker can shut down cleanly, but it also needs to be safe if it is retried. Idempotency means running the same job more than once should not create duplicate side effects. For example, if a job sends an invoice email or charges a payment, I need a way to know whether that action already happened. Cancellation should not leave the system in an unknown state without a recovery path.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
In practice, I would store job state and use idempotency keys around external side effects. If a worker is cancelled while processing, the job can be marked for retry unless it passed a commit point. For example, after sending a payment request, the next run may need to query provider status instead of sending the payment again. The trade-off is more state and workflow logic, but that is better than duplicate charges or missing messages.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I separate interruptible work from commit-point work. Reading data or preparing a file can usually honor cancellation. Once I publish an event, call a payment provider, or write durable state, I need idempotency, reconciliation, and clear status transitions. I design jobs so crashes and retries are expected, not exceptional. I also monitor retry count, poison jobs, processing duration, and duplicate-prevention hits, because those metrics reveal whether the workflow is stable or barely surviving.

Coding practice

Practice the problem like a real interview: restate, reason, implement, and test.

ExampleCandidatePractical exampleWalk through sample input and output.Open details

Details

if (await _processedJobs.ExistsAsync(job.Id, ct))
    return;

await _paymentProvider.CaptureAsync(job.PaymentId, idempotencyKey: job.Id.ToString(), ct);
await _processedJobs.MarkProcessedAsync(job.Id, ct);

The idempotency key lets the external provider treat retried calls as the same logical operation.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Retrying side effects without idempotency.
Cancelling halfway through a commit point with no reconciliation.
Treating every retry as safe because the code is inside a background job.
Not recording job state transitions.
Ignoring poison-message handling.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Do not treat retrying the job as sufficient. Define which side effects can repeat, where the durable commit points are, and how an interrupted job resumes or reconciles without duplicating externally visible work.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you avoid sending the same email twice?
What is a poison job?
When should a cancelled job be retried?
How do you reconcile unknown payment status?

Interviewer notesInterviewerInterviewer notesWhat the interviewer is listening for.Open details

Details

Look for real workflow safety. Strong answers mention idempotency, retries, durable state, and cancellation boundaries.

Recruiter notesRecruiterRecruiter notesHow to frame the answer for screening conversations.Open details

Details

This checks whether the candidate can build reliable background processing, which is common in backend systems.

Continue the section

Next in Parallel Workloads: Limit External Calls

Step 5 of 12

Limit concurrency for external API calls

Opening drill

if (await _processedJobs.ExistsAsync(job.Id, ct)) return; await _paymentProvider.CaptureAsync(job.PaymentId, idempotencyKey: job.Id.ToString(), ct); await _processedJobs.MarkProcessedAsync(job.Id, ct);

How do cancellation and idempotency change the way you design background jobs?

Practice focus

Answer path

Why this question matters

Coding practice

Review signals

Follow-up prompts

Continue the section

How do cancellation and idempotency change the way you design background jobs?

Practice focus

Answer path

Why this question matters

Coding practice

Review signals

Follow-up prompts

Continue the section