Boost API Performance: Proven Indexing, Caching, and Async Strategies for Java Backends

Preface

Interface performance optimization is a common problem for backend developers, independent of language. The causes are varied, from missing indexes to code refactoring, caching, middleware, sharding, or service splitting.

1. Index

Optimizing indexes is the cheapest way. Use

show index from `order`

or

show create table `order`

to view indexes. Add indexes with

ALTER TABLE `order` ADD INDEX idx_name (name)

or

CREATE INDEX idx_name ON `order` (name)

. To modify an index, drop it first with

DROP INDEX idx_name ON `order`

.

1.1 No index

If the

WHERE

or

ORDER BY

columns lack an index, performance degrades as data grows. Use the commands above to add missing indexes.

1.2 Index not used

Run

EXPLAIN SELECT * FROM `order` WHERE code='002'

to see whether the index is applied. Common reasons for index loss are shown in the attached diagrams.

1.3 Wrong index chosen

MySQL may pick an inappropriate index; you can force a specific index with

FORCE INDEX

.

2. SQL Optimization

If indexing does not help, rewrite the SQL. Fifteen small tricks are listed in a separate article.

3. Remote Calls

Serial remote calls add up latency. Parallel calls using

Callable

(pre‑Java 8) or

CompletableFuture

(Java 8+) can reduce total time to the longest single call.

3.1 Parallel Invocation

Example using

CompletableFuture.supplyAsync

with a custom executor to fetch user, bonus, and growth data concurrently.

3.2 Data Duplication

Store frequently needed data (e.g., user profile, points, growth) in Redis to avoid remote calls entirely, while being aware of consistency issues.

4. Repeated Calls

Batch queries instead of looping individual lookups. Use

SELECT ... WHERE id IN (…)

to fetch many rows in one round.

4.1 Looping DB queries

Replace per‑user queries with a single batch query.

4.2 Infinite loops

Beware of

while(true)

loops and CAS spin locks that can become dead‑locks if exit conditions fail.

4.3 Infinite recursion

Limit recursion depth when traversing hierarchical data to prevent stack overflow.

5. Asynchronous Processing

Separate core business logic from non‑core tasks (notifications, logging) using thread pools or MQ.

5.1 Thread Pool

Submit auxiliary tasks to dedicated thread pools to keep the main request fast.

5.2 MQ

Publish messages to a queue; consumers handle the work asynchronously.

6. Avoid Large Transactions

Large

@Transactional

scopes can cause timeouts. Keep reads outside transactions, avoid remote calls inside, and limit batch sizes.

7. Lock Granularity

Use fine‑grained

synchronized

blocks instead of method‑level locks. For distributed systems, employ Redis, Zookeeper, or DB based distributed locks.

7.2 Redis Distributed Lock

Typical pattern:

SET lockKey requestId NX PX expireTime

and delete with a Lua script.

7.3 Database Locks

Prefer row‑level locks over table locks for higher concurrency.

8. Pagination

Split large batch requests into smaller pages, using Guava's

Lists.partition

for synchronous or

CompletableFuture

for asynchronous pagination.

9. Caching

Cache hot data in Redis or a second‑level in‑memory cache (Caffeine) to reduce DB load, while handling cache invalidation.

10. Sharding (Database & Table)

When a single database becomes a bottleneck, split into multiple databases and tables using modulo, range, or consistent‑hash routing.

11. Auxiliary Tools

Enable MySQL slow‑query log, monitor with Prometheus, and trace requests with SkyWalking to quickly locate performance bottlenecks.