Master Asynchronous Writes: Thread Pools, In‑Memory Queues & MQ for High‑Concurrency

1 Business Scenario

Teachers log into an education platform, view a list of courses, and watch video content. The course detail page performs two core actions: retrieving video information from a Redis cache and recording viewing behavior in the database every three seconds, causing write load to grow exponentially with user count.

Initially the system performed adequately, but as concurrent users increased, response times slowed and many threads blocked on the DAO method that writes video progress.

Typical approaches focus on boosting database write capacity—optimizing SQL, upgrading MySQL hardware, or sharding tables—but these are costly and may be unnecessary if writes can tolerate slight delays or data loss.

The optimization goal is to reduce write latency and increase write concurrency , allowing the system to run smoothly.

Five asynchronous strategies are considered:

Thread‑pool model

Local memory + scheduled task

Message‑queue (MQ) pattern

Agent service + MQ pattern

2 Thread‑Pool Model

In a previous high‑traffic coupon system, a controller placed write operations into a dedicated thread pool and returned immediately to the front end, while the pool executed the writes asynchronously, stabilizing the service.

Applying a similar model to the education platform involves a thread pool that processes video‑watch records asynchronously.

Key considerations:

Limit thread count to avoid exhausting database connections.

Size the thread‑pool queue appropriately to prevent memory overflow.

3 Local Memory + Scheduled Task

Inspired by a popular open‑source solution, incoming view events are stored in an in‑memory LinkedBlockingQueue. A background thread periodically (e.g., every minute) batches the queued records and writes them to MySQL using Jdbc batchUpdate. This approach requires no changes to existing business logic and offers high throughput, though memory usage must be monitored.

4 MQ Pattern

Message queues provide asynchronous, decoupled processing. The flow is:

Controller converts a write request into a message.

The service publishes the message to the MQ and immediately returns success to the front end.

A consumer service pulls messages from the MQ and performs batch database writes.

Advantages include high availability, efficient asynchronous delivery, and persistent storage on the MQ server, but it introduces an additional component and complexity.

5 Agent Service + MQ Pattern

An alternative is to have an Agent process write requests: the service writes the request as a JSON file to disk, returns success, and the Agent watches the file, forwards its content to the MQ, and a consumer persists the data to MySQL. This layered architecture keeps the core service free of MQ dependencies while still gaining asynchronous benefits.

6 Summary

Understanding when to apply asynchronous techniques involves three layers:

When: Massive write operations consume excessive resources and can tolerate slight delays.

How: Choose among thread‑pool, in‑memory + scheduled task, MQ, or Agent + MQ approaches, all of which store write commands in a pool and respond instantly to the front end.

Why: Asynchrony enables finer‑grained resource utilization, preventing non‑critical writes from blocking core business flows.

Effective asynchronous design must balance resource usage, latency tolerance, and system complexity to achieve the desired performance gains.