18 Proven Strategies to Supercharge Backend API Performance

Introduction

During a previous project I encountered a 504 timeout caused by an interface taking longer than the Nginx 10‑second limit. After performance tuning, the response time dropped from 11.3 seconds to 170 ms. Below are several general optimization methods.

1. Batch Thinking: Batch Database Operations

Before optimization:

//for loop single insert
for (TransDetail detail : transDetailList) {
    insert(detail);
}

After optimization:

batchInsert(transDetailList);

Analogy: Moving 10,000 bricks with an elevator that can carry up to 500 bricks at a time is far faster than moving one brick per trip.

2. Asynchronous Thinking: Offload Time‑Consuming Operations

Place long‑running tasks in asynchronous processing to reduce interface latency. For example, a transfer‑matching operation can be performed asynchronously, allowing the API to return quickly.

3. Space‑for‑Time Thinking: Use Caching Appropriately

Cache frequently accessed data (Redis, JVM local cache, Memcached, Map, etc.) to avoid repeated database queries and calculations.

In a transfer interface, the original code queried the database for each transaction to match bank codes. After introducing a cache, the process became much faster.

4. Prefetch Thinking: Initialize Data into Cache Early

Pre‑compute complex data and store it in cache before it is needed, reducing real‑time computation cost. This technique was used in a video‑live streaming project to preload user and score information.

5. Pooling Thinking: Preallocate and Reuse

Thread pools, connection pools, and other resource pools avoid the overhead of creating and destroying resources repeatedly.

Thread pools manage threads, preventing the cost of frequent thread creation and destruction.

6. Event Callback Thinking: Avoid Blocking Wait

Instead of blocking on a slow external system (e.g., waiting 10 seconds for system B), use an event‑callback model to continue other work and handle the result when it arrives.

7. Remote Calls: Serial to Parallel

Parallelize independent remote calls (e.g., fetching user info, banner, and popup data simultaneously) to dramatically cut total latency.

8. Lock Granularity: Avoid Too Coarse Locks

Lock only the necessary critical section (e.g., lock the list rather than the whole object) to prevent contention and improve concurrency.

Locking the entire house when only the bathroom needs to be locked is unnecessary.

9. Switch Storage: File‑Based Temporary Data

When database inserts become a bottleneck for massive data, temporarily store the data in files and asynchronously write to the database later, achieving a ten‑fold performance boost.

10. Index

Adding appropriate indexes is a low‑cost yet effective optimization.

Ensure SQL statements have indexes on filtered columns.

Verify that indexes are actually used.

Design indexes reasonably (avoid redundant indexes, limit to ~5 per table, avoid low‑cardinality columns, consider covering indexes, use FORCE INDEX only when necessary).

10.1 SQL Without Index

explain select * from user_info where userId like '%123';

10.2 Index Not Effective

Common reasons for index loss are illustrated in the accompanying diagram.

10.3 Bad Index Design

Remove redundant or duplicate indexes.

Limit the number of indexes per table.

Avoid indexing columns with many duplicate values (e.g., gender).

Use covering indexes when appropriate.

Re‑evaluate the need for FORCE INDEX.

11. Optimize SQL

Beyond indexing, SQL can be refined in many ways; see the referenced articles for detailed techniques.

12. Avoid Large Transaction Issues

Embedding remote RPC calls or heavy operations inside a Spring @Transactional method can cause long‑running transactions, leading to connection pool exhaustion and degraded performance.

Long‑running transactions hold database connections, causing timeouts, deadlocks, and replication lag.

Do not place RPC calls inside transactions.

Keep query‑related work outside transactions when possible.

Avoid processing large amounts of data within a single transaction.

13. Deep Pagination Issues

Using LIMIT offset, count with large offsets forces the database to scan and discard many rows, slowing queries.

13.1 Tag Record Method

Record the last processed primary‑key value and query from that point onward, e.g.:

select id, name, balance FROM account where id > 100000 limit 10;

13.2 Delayed Association Method

First fetch primary keys via a secondary index, then join back to the main table to avoid full scans:

select acct1.id, acct1.name, acct1.balance FROM account acct1 INNER JOIN (
    SELECT a.id FROM account a WHERE a.create_time > '2020-09-19' limit 100000, 10
) AS acct2 ON acct1.id = acct2.id;

14. Optimize Program Structure

Reorder conditional checks to reduce unnecessary evaluations, e.g., check the less‑frequent condition first.

15. Compress Transfer Content

Compressing payloads reduces bandwidth usage and speeds up transmission.

A lighter load (e.g., a horse carrying 10 kg) moves faster than a heavier one.

16. Massive Data Handling: Consider NoSQL

For very large datasets, use NoSQL solutions such as Elasticsearch or HBase, or apply sharding and partitioning if relational storage is required.

17. Thread Pool Design Should Be Reasonable

Configure core size, maximum size, and queue capacity appropriately; avoid OOM caused by unbounded queues and ensure business isolation.

18. Machine Issues (Full GC, Thread Saturation, Unclosed IO)

System‑level problems like frequent Full GC, thread exhaustion, or leaked IO resources can also degrade API performance.

Exporting massive Excel files with Apache POI can trigger Full GC and cause hangs.

By applying the above 18 optimization techniques, you can significantly improve backend API response times.