Asynchronous Apex Interview Questions: Choose Queueable or Batch and Define Partial Failure

An asynchronous Apex answer should tell the interviewer what commits when work fails. Choose Queueable for a bounded job or an explicit dependency chain; choose Batch when a large dataset needs separate processing transactions. Then define record-level results, transaction rollback and retry identity independently. “It runs in the background” does not answer any of those questions.

Official Salesforce documentation supports the platform mechanics below. The six-record ledger is an original exercise checked with a local Python model, not an executed Salesforce org test. Start with PracHub's idempotent versioned update exercise if you need practice explaining why retrying the same logical work must differ from creating new work.

Choose a unit of work before choosing an interface

Suppose a fictional account-enrichment process handles records A through F. Each record receives a normalized classification and produces a downstream notification. One record is invalid, and the upstream caller may submit the same request again. The interview task is to make progress without claiming that every operation either happened everywhere or happened nowhere.

Ask whether the input is already a small known collection, whether records depend on preceding results, and whether the whole selection fits one transaction's limits. Also ask whether the notification is a database record or an actual remote request. Those answers identify the effects a failure can leave behind.

Official facts: Salesforce's Queueable module describes submitting a job with System.enqueueJob, obtaining an AsyncApexJob identifier and chaining dependent work. Its Batch module describes processing large selections in separate transactions. Successful batch transactions are not rolled back because another batch transaction fails. It also warns that chunks are not guaranteed to execute in selection order.

These are editorial decision rules, not universal performance rankings. A design can use both mechanisms, but drawing more boxes does not automatically create a reliable workflow.

Trace a failed chunk through the committed database

Divide the six records into three fictional chunks: A/B, C/D and E/F. For this trace, process chunk 1, then chunk 2, then chunk 3. That order makes the example readable; the design must remain correct if the platform schedules independent chunks differently.

Chunk 2 throws an unhandled exception while processing C. Treat every database write in that chunk's transaction as rolled back. It is incorrect to keep D merely because its update appeared earlier in a log.

The local model checks that the final committed set is A, B, E and F. This checks the stated transaction ledger; it does not reproduce Salesforce governor behavior, trigger execution or actual batch scheduling. In an org, verify those concerns with Apex tests and appropriate integration evidence.

Now change the requirement: D should succeed even when C is invalid. That is a different policy. It requires record-level error handling within the chunk, followed by a successful transaction commit. Batch selection alone does not implement record-level partial success.

Separate partial DML results from transaction durability

Official reference: Salesforce's Database upsert example demonstrates partial processing and inspecting individual results. A result saying one record succeeded describes that DML operation's outcome. The surrounding transaction still matters.

With a partial-success operation, C can return an error while D returns success. If the code handles C's error, records the required information and reaches commit, D can persist. If later code throws an unhandled exception, D's earlier successful write can still roll back with the transaction. “I set partial success, so good rows always survive” is therefore an incomplete answer.

// Illustrative fragment; object names and tests belong to your org.
Database.SaveResult[] results = Database.update(records, false);
for (Integer i = 0; i < results.size(); i++) {
    if (!results[i].isSuccess()) {
        // Associate every error with records[i].Id and this logical request.
        // Decide whether to continue, retry later, or reject the chunk.
    }
}
// Successful rows become durable only if the transaction commits.

The snippet is intentionally not presented as a complete deployable class. It omits schema-specific fields, authorization decisions, error persistence and test data. In an interview, say which of those you would implement next instead of letting pseudocode imply they already work.

An error record inserted in the same transaction can disappear when that transaction rolls back. Decide whether the desired evidence comes from the platform job record, a separately persisted outcome, a supported finalization mechanism or a later reconciliation pass. Each option has its own failure boundary. Printing a message is not a durable retry plan.

Give retries a logical identity

Repair C and rerun only C/D, or rerun the original selection with deduplication. Both can be defensible. What matters is the meaning of “already done.” A new platform job ID identifies an attempt; it does not necessarily identify a new business operation.

For the original exercise, use a stable logical request key plus record identity and a version of the requested transformation. A unique persisted key prevents two attempts from creating two completion records for the same work. If the transformation is an upsert to a known state, replay should converge to that state rather than incrementing an amount again.

The Python ledger replays C/D twice under the same logical keys and ends with six unique effects. An implementation that appends an effect on every attempt would produce duplicates. This distinction is the purpose of the test; the model does not establish that a particular Salesforce schema has the needed uniqueness constraint.

Concurrent retries need more than a “check, then insert” sequence. Two workers can both observe absence. Use an actual uniqueness or concurrency strategy and handle its conflict result. A design that is safe only when requests happen one at a time has not resolved the duplicate problem.

Explain what a Queueable chain guarantees

A chain expresses that one job submits its successor. Salesforce's Queueable guidance limits an executing job to one enqueued child; consult current limits and org configuration before quoting depth or capacity numbers. The useful interview issue is the dependency, not memorizing a limit divorced from the environment.

If a parent fails before successfully committing its work and successor submission, do not assume the rest of the chain will appear automatically. Name the failure recovery owner. That might be an operator, a reconciler or a deliberately designed recovery mechanism; it must not be an unexplained arrow labeled “retry.”

Also distinguish a chain's ordering from unrelated queued work. Submitting two independent jobs does not prove their business effects occur in the order the caller expects. If one operation requires another's committed result, represent and verify that dependency explicitly.

For the account exercise, a short chain might normalize a bounded set, then aggregate its committed outcome. A Batch implementation might normalize independent scopes and summarize the overall result afterward. Neither choice makes partially failed records magically complete. The summary must distinguish successful, rejected, retriable and still-unknown work.

Keep external delivery outside the rollback promise

Suppose the enrichment transaction sends a request to another service. The receiver accepts it, but the local transaction later fails. Rolling back Salesforce data does not retract a remote acceptance. Conversely, a network timeout does not prove the remote service did nothing.

A practical design separates the desired notification from its delivery attempt. Persist an identifiable delivery intent with the business change when the chosen platform mechanism supports the required transaction relationship. A delivery worker can then send, record acknowledgments and reconcile ambiguous timeouts. State the exact platform feature you would use and verify its guarantees; this article's ledger is not an implementation of an outbox service.

Even with a persisted intent, “exactly once” needs qualification. A crash after remote acceptance but before recording the acknowledgment can cause another send. The receiver's idempotency key or a readback protocol must resolve that window. If the receiver offers neither, explain the remaining duplicate risk and the business reconciliation policy.

For additive operations, include a test that retries after an ambiguous acknowledgment. Checking only a final classification field can miss duplicate emails, charges or downstream counters. Test the effect the business actually cares about.

Show tests that distinguish the failure boundaries

Prepare a small test matrix before writing a large Apex class. Include a successful bounded job, an invalid record under partial DML, an unhandled exception after a successful DML result, a failed independent chunk, and two attempts with the same logical key. Assert persisted records and result associations, rather than merely that code reached a line.

Use Salesforce's asynchronous testing guidance for the concrete job mechanism, and separate tests of chained scheduling from tests of each worker's business logic. A local Python model cannot validate Test.startTest/Test.stopTest, trigger interactions, callout mocks or permission behavior. It can still expose an inconsistent transaction story before you enter the org.

The existing Apex trigger preparation article covers bulk collections and trigger recursion. Bring those concerns into each chunk when relevant, while retaining the separate asynchronous commit boundary developed here.

Make the operator's next action unambiguous

The business outcome should distinguish a completed attempt from completed work. In the fictional process, an operator seeing A, B, E and F must be able to identify C and D as the failed transaction's unresolved scope. If record-level partial processing was chosen instead, only C may remain unresolved. An aggregate count of four or five successes without the policy and record mapping is not enough to choose a retry.

Retain the logical request identity, transformation version and each record's durable outcome. When a rerun begins, record a new attempt without discarding the previous evidence. This lets you explain why a repeated submission reused D's result rather than silently hiding a second effect. Avoid storing sensitive payloads merely to make debugging convenient; the useful evidence is the minimum needed to identify and reconcile the work.

In an interview, ask your partner to play the operator and choose the next action from your ledger alone. If they cannot distinguish invalid data from an ambiguous external acknowledgment, improve the states before adding automatic retries. Automation that cannot tell those cases apart can repeat the wrong action more quickly.

Practice the design with related PracHub questions

The bank does not supply five dedicated Queueable/Batch exercises for this article. These verified questions cover transferable retry, transaction, batching and review skills. Their languages and platforms differ, so answer with the Salesforce-specific boundary rather than treating the original question as an Apex specification.

Rehearse the idempotent update question using the six-record ledger. Explain what survives chunk 2, what changes under partial DML, and how a second C/D attempt avoids a duplicate notification. Name the persisted state and the unresolved external outcome.

Sources and Further Reading

• Salesforce Trailhead: Control processes with Queueable Apex
• Salesforce Trailhead: Use Batch Apex
• Salesforce Apex Developer Guide: Database upsert with partial processing