How to Boost High‑Concurrency Systems with Asynchronous Architecture Patterns

1. Business Scenario

In a teaching platform, a teacher logs in, selects a course, and watches video content. The front end performs two core actions: (1) fetch video metadata from Redis and render it, and (2) every three seconds send a request to record the watch behavior, inserting a row into a MySQL table. As concurrent users increase, the write operations saturate the database, causing many threads to block on the DAO method.

2. Thread‑Pool Pattern

Inspired by a past experience with a high‑traffic red‑packet system, the write request is handed off to a dedicated thread pool, and the controller returns immediately. This decouples the response time from the actual database write, eliminating time‑outs. Key considerations: keep the pool size modest to avoid exhausting DB connections, and size the queue carefully to prevent out‑of‑memory errors.

3. Local Memory + Scheduled Task

Following a classic Oschina approach, incoming watch records are placed into a LinkedBlockingQueue in memory. A background thread runs every minute, drains the queue, assembles a List, and calls Jdbc.batchUpdate to write the batch. This dramatically improves throughput without changing the existing business flow, but the in‑memory queue must be bounded to avoid memory overflow.

4. MQ Pattern

The write request is transformed into a message and sent to a message queue. The service acknowledges success to the front end instantly. A consumer service pulls messages from the queue and performs batch inserts into MySQL. Advantages include high availability, persistence, and efficient batch consumption; the downside is the added complexity of managing an MQ component.

5. Agent Service + MQ Pattern

An independent Agent process runs on the teaching server. After receiving a write request, the service writes the data to a file (e.g., JSON) and returns success. The Agent watches the file, pushes its content to the MQ, and a consumer persists the records to MySQL. This architecture offers clear layering and avoids embedding MQ logic directly in the business service.

6. Summary

The article structures thinking into three layers: when asynchronous processing is required, the four concrete async techniques, and the underlying principle that async is a finer‑grained way to use system resources. It warns against “async for the sake of async”—any async solution must still respect database resource limits, otherwise the intended performance gains are lost.

Thread‑Pool Pattern

Local Memory + Scheduled Task

Message‑Queue (MQ) Pattern

Agent Service + MQ Pattern