Common Interface Performance Optimization Strategies for Backend Systems

Background

Many legacy projects suffer from excessive interface latency due to repeated inefficiencies. The following sections summarize a series of generic optimization methods that can be applied to improve API performance.

1. Batch Processing

Group database operations into a single batch to reduce I/O overhead. Instead of inserting records one by one, collect them and execute a bulk insert.

// for‑loop single insert
list.stream().forEach(msg -> {
    insert();
});
// batch insert
batchInsert();

2. Asynchronous Processing

Offload long‑running, non‑critical tasks to asynchronous execution (thread pool, message queue, or scheduled jobs) to lower request latency.

Example: In a financial purchase API, the accounting and file‑writing steps can be performed asynchronously because they are not required for the immediate response.

3. Space‑for‑Time (Caching)

Cache frequently accessed, rarely changed data to avoid repeated database queries or calculations. Use appropriate cache solutions such as Redis, Memcached, local maps, or R2M.

4. Pre‑Processing

Pre‑compute and store results (e.g., annualized return rates for financial products) so that API calls can retrieve ready‑made values instead of performing calculations on the fly.

5. Pooling

Reuse expensive resources like database connections or threads via pooling to avoid the overhead of repeated creation and destruction.

6. Serial to Parallel

Execute independent tasks in parallel rather than sequentially, provided there are no result dependencies, to reduce overall latency.

7. Indexing

Properly add indexes to improve query efficiency. The article notes common scenarios where indexes may not be effective.

8. Avoid Large Transactions

Large, long‑running transactions hold database connections and can cause timeouts or deadlocks. Keep transactions short and move non‑DB calls (e.g., RPC, push notifications) outside the transaction.

@Transactional(value = "taskTransactionManager", propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED, rollbackFor = {RuntimeException.class, Exception.class})
public BasicResult purchaseRequest(PurchaseRecord record) {
    BasicResult result = new BasicResult();
    // insert account task
    taskMapper.insert(ManagerParamUtil.buildTask(record, TaskEnum.Task_type.pension_account.type(), TaskEnum.Account_bizType.purchase_request.type()));
    // insert sync task
    taskMapper.insert(ManagerParamUtil.buildTask(record, TaskEnum.Task_type.pension_sync.type(), TaskEnum.Sync_bizType.purchase.type()));
    // insert file upload task
    taskMapper.insert(ManagerParamUtil.buildTask(record, TaskEnum.Task_type.pension_sync.type(), TaskEnum.Sync_bizType.cert.type()));
    result.setInfo(ResultInfoEnum.SUCCESS);
    return result;
}

When additional RPC calls (e.g., push notifications) are added inside the transaction, they can exacerbate the large‑transaction problem.

@Transactional(value = "taskTransactionManager", propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED, rollbackFor = {RuntimeException.class, Exception.class})
public BasicResult purchaseRequest(PurchaseRecord record) {
    BasicResult result = new BasicResult();
    // ... other inserts ...
    pushRpc.doPush(record);
    result.setInfo(ResultInfoEnum.SUCCESS);
    return result;
}

Mitigation strategies:

Do not place RPC calls inside transactions.

Perform read‑only queries outside transactions.

Avoid processing excessive data within a single transaction.

9. Refactor Program Structure

After multiple iterations, code can become tangled with redundant queries and object creations. Refactor to evaluate each block's purpose, reorder execution, and eliminate unnecessary work.

10. Deep Pagination Issues

Using LIMIT offset, count on large offsets forces the database to scan many rows. Replace with a "keyset" pagination approach that leverages indexed columns.

SELECT * FROM purchase_record WHERE productCode = 'PA9044' AND status = 4 AND id > 100000 LIMIT 200;

11. SQL Optimization

General SQL tuning—leveraging indexes, proper pagination, and selective column retrieval—can dramatically improve query performance.

12. Lock Granularity

Use fine‑grained locks (e.g., synchronize only the critical shared resource) instead of coarse locks that block unrelated operations.

// Incorrect: locking non‑shared code
private void notShare() {}
private void share() {}
private int wrong() {
    synchronized(this) {
        share();
        notShare();
    }
}

// Correct: lock only shared part
private void notShare() {}
private void share() {}
private int right() {
    notShare();
    synchronized(this) {
        share();
    }
}

Conclusion

Interface performance problems usually accumulate over iterative development. By adopting the above systematic approaches—batching, async, caching, pre‑processing, pooling, parallelism, indexing, transaction hygiene, pagination, SQL tuning, and proper locking—developers can achieve significant latency reductions and maintainable, cost‑effective backend services.

Feel free to discuss these ideas, ask questions, or share your own experiences.