Business Exception or System Exception on a Missing Mandatory Field
A process validates customer onboarding records from a work queue. Each record must contain a tax identifier and a bank account. During a pilot, 12 percent of records arrived without a tax identifier because an upstream team's export omits the field when it is blank. The current process throws a System Exception when the field is empty, which marks the item as failed and consumes a retry, then routes it to the Exception queue with a generic message. The operations lead reports that the same records are retried three times, fail three times, and then sit in the queue with no indication of what is wrong. Separately, about 1 percent of records fail when the core banking API returns a 503 during peak hours; those also go to the Exception queue and are cleared manually.
1. Classify each failure correctly and explain the consequences of the current misclassification.
Read the worked answer
The missing tax identifier is a Business Exception: the data is invalid and no amount of retrying will fix it. The 503 from the core banking API is a System Exception: the data is fine, the environment failed, and a later retry may succeed.
The current design treats both as System Exceptions, which has three costs. First, it wastes capacity: each of the 12 percent of records with no tax identifier is attempted three times, so roughly a third of the queue's processing is spent re-failing known-bad data. Second, it corrupts the operational signal - the Exception queue mixes recoverable environment failures with records that need upstream correction, so the team cannot tell which items to retry and which to send back. Third, the generic message destroys the diagnostic value: a reviewer cannot see that the tax identifier was blank, so clearing takes longer than it should.
The fix is to validate mandatory fields before any API call and throw a Business Exception with a specific reason, for example 'Tax identifier missing on source record', and to let the queue mark the item as an exception without consuming retries. The API 503 should remain a System Exception with retry and backoff, so transient peak-hour failures recover automatically. The two paths should be visibly distinct in reports so the upstream export defect is tracked as a data-quality issue rather than absorbed silently by operations.
2. Design the recovery path for each class, including what should be recorded on the queue item and who acts.
Read the worked answer
For the Business Exception, the process should stop before calling the API, set the item status to exception with a specific reason code and a human-readable message naming the missing field, and route it to a data-correction queue owned by the upstream team. No retry should be consumed. The item should carry the source record reference and the field name so the upstream team can fix the export. Once corrected, the item is re-queued and processed normally. The operations team should not be the owner of this path; the upstream data owner is, because the defect originates there.
For the System Exception, the process should retry the API call a bounded number of times with increasing delay, and only then mark the item as a System Exception with the HTTP status, timestamp, and endpoint recorded in the exception detail. The queue's own retry mechanism should re-queue it for a later attempt, ideally with a deferral so it is not retried instantly into the same peak. Operations owns this path and monitors the rate; a sustained rise in 503s should raise an alert to the integration team rather than being cleared item by item.
Both paths should write a consistent reason code so dashboards can separate data defects from environment failures, and both should avoid logging sensitive values such as the bank account number. The design principle is that the exception type determines the owner, the retry behaviour, and the reporting category - one decision, applied consistently.