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.