15 Proven Techniques to Optimize API Performance

1. Local Cache

Local cache runs in the same process as the application, offering ultra‑fast access without network overhead, making it suitable for single‑instance or clustered scenarios where nodes do not need to synchronize caches. Its drawbacks are memory waste due to lack of sharing and coupling with the application. Common libraries are Guava and Caffeine, which are simple JAR dependencies.

Low entry barrier; tutorials are widely available.

Suitable when cached data is not time‑critical and can tolerate slight staleness; short TTL can keep data fresh.

Ideal for immutable mappings such as order‑id to user‑id.

Control the maximum number of entries to avoid excessive memory consumption.

Define eviction policies to remove stale entries.

Prefer mature open‑source implementations to avoid hidden pitfalls.

2. Distributed Cache

Distributed caches externalize state, allowing horizontal scaling and independent operation, at the cost of a 1–2 ms network latency, which is negligible compared with the benefits. Popular systems include Memcached and Redis, which can achieve over 80 k QPS on a single node. Shifting read/write pressure from the relational database to the cache protects the database from overload.

Cache hit rate must be high enough to relieve downstream storage.

Capacity planning is required to prevent hot‑data eviction.

Data consistency mechanisms must be considered.

Fast scaling strategies are needed.

Monitor average, max, and min response times (RT) and QPS.

Watch network egress traffic and client connection counts.

3. Parallelism

Map the business flow, draw a sequence diagram, and identify serial versus parallel steps. Exploit multi‑core CPUs by processing independent tasks in parallel. Java's CompletableFuture provides about 50 APIs for composing serial, parallel, and error‑handling pipelines.

4. Asynchrony

Interface response time is dominated by the complexity of internal business logic. Separate non‑core operations (e.g., sending SMS after order creation) and execute them asynchronously. In an e‑commerce order API, the core task is persisting the order; notifications are off‑loaded to a message queue using a publish/subscribe pattern.

5. Pooling

TCP three‑way handshake incurs overhead; keep‑alive connections avoid frequent creation/destruction. Pool reusable objects (threads, memory, DB connections, HTTP clients) to reduce allocation cost. Connection pools typically configure minimum, idle, and maximum connections.

Key parameters: min connections, idle connections, max connections.

new ThreadPoolExecutor(3, 15, 5, TimeUnit.MINUTES,
    new ArrayBlockingQueue<>(10),
    new ThreadFactoryBuilder().setNameFormat("data-thread-%d").build(),
    (r, executor) -> {
        if (r instanceof BaseRunnable) {
            ((BaseRunnable) r).rejectedExecute();
        }
    });

6. Sharding (Database Partitioning)

MySQL InnoDB uses a B+‑tree structure that supports tens of millions of rows. For massive user bases, a single table cannot meet performance needs; horizontal sharding splits a large table into multiple identical physical tables, relieving storage and access pressure. However, sharding introduces challenges such as data skew, global unique ID generation, and routing logic.

7. SQL Optimization

Poor SQL dramatically degrades API performance. Typical problems include deep pagination causing massive pre‑fetches, missing indexes leading to full‑table scans, and queries that return tens of thousands of rows. Recommended practices:

Avoid SELECT *; specify required columns.

Use LIMIT 1 when only a single row is needed.

Keep the number of indexes per table under five.

Prefer AND over OR in WHERE clauses to preserve index usage.

Do not index columns with high duplication (e.g., gender).

Index columns used in WHERE and ORDER BY to avoid full scans.

8. Pre‑Computation

Complex calculations (e.g., site PV, red‑packet distribution) are unsuitable for real‑time execution. Pre‑compute results and warm them into cache; the API then reads from cache, achieving a noticeable speed boost.

9. Transaction Management

Transactions guarantee consistency but consume resources. Reduce transaction scope to finish quickly and free DB connections. Move non‑critical queries outside the transaction and avoid remote RPC calls within a transaction.

10. Bulk Read/Write

IO is often the bottleneck. For fetching 100 account balances, two designs exist: (1) a single‑call API with the client looping 100 times, or (2) a batch‑query API where the client calls once. The batch approach is clearly superior and is also applied to bulk database updates.

11. Lock Granularity

Locks protect shared resources but must be used judiciously. Over‑locking non‑contended resources harms concurrency. Focus on minimizing lock scope to the smallest necessary critical section.

12. Context Propagation

Repeated RPC calls for the same data waste resources because method locals are discarded after stack frames unwind. Introducing a shared Context object to carry intermediate data reduces redundant lookups.

13. Collection Size

When inserting one million elements into a List, pre‑allocating capacity improves performance. Experiments show:

Scenario 1 (default capacity): 1,000,000 inserts took 154 ms.

Scenario 2 (pre‑sized): 1,000,000 inserts took 134 ms.

ArrayList expands by 1.5× once the threshold is exceeded, causing data copying and performance loss.

14. Query Optimization

Avoid pulling massive data sets into memory; instead use batch or paginated queries to prevent OOM and reduce latency.