Boost System Performance with a Practical Asynchronous Processing Pattern

Recently a system has suffered prominent performance problems such as frequent database table scans, response timeouts, and high CPU usage. A colleague proposed a purely technical solution, listing possible technical causes and categorizing each program. While technically correct, this approach is not appropriate from a business perspective because the current focus should be on delivering business capability, not merely analyzing technical dimensions.

The priority is to rank functional services by importance and urgency, apply the most effective technical measures, and quickly improve performance to avoid impacting online services. Not every possible improvement needs to be fully implemented; the analysis should be vertical—by functional dimension—rather than a horizontal, technology‑first sweep. Asynchronous processing is generally the most effective way to boost performance in OLTP systems, and a generic asynchronous implementation pattern is presented.

1. Request Reception

The reception step is straightforward: a consumer sends a single or batch processing command, the application stores the command in the database, and then returns a success or failure status for the command receipt. Note that this status reflects only the receipt outcome, not the business execution result, which is obtained in the next step.

2. Backend Processing

After commands are persisted, an event‑notification mechanism or a background‑thread scanner should locate pending tasks in the command store. This involves concerns such as task competition, consistency guarantees, and unique‑execution guarantees, which are covered elsewhere.

If the backend also processes tasks asynchronously, the final result must be awaited via a callback or a separate thread that queries and updates the result. For synchronous tasks, the business execution result typically falls into three states: success, failure (business‑level failure), or exception (e.g., network interruption, timeout). Success is simple; failure handling is described in section 4; exceptions require an "exception retry" process.

3. Exception Retry

Exceptional business cases generally require a retry, which includes two scenarios:

If the counterpart successfully completed the business but the connection broke, the consumer did not receive the response. In this case, retrieve the result, update the business state, and continue the workflow.

If the counterpart did not receive the request or encountered an error, and business idempotency is ensured, a backend thread can re‑initiate the call.

Both scenarios must be handled according to the backend service’s mechanisms.

4. Failure Compensation

Here, "failure" refers to normal processing that returns a failure status. Depending on the business model, one must decide whether to retry or treat the status as final, notify the upstream caller, and perform subsequent handling. The retry mechanism mirrors the one described in the previous section.

5. Business Alerts

Asynchronous processing often hides backend activity, making it difficult to monitor internal processing because background threads do not directly return results to callers. Therefore, a robust alerting mechanism is essential to detect and track business exceptions before they reach customers as complaints.