When Monolith Meets Microservices: API Composition vs CQRS for Complex Queries

Background

During technical interviews, candidates often praise micro‑service architectures while overlooking the practical pain points that arise when a small‑to‑medium system grows beyond a simple monolith. In a monolithic design, developers can rely on multi‑table SQL queries for high development speed, but as business complexity and team size increase, the same approach forces costly distributed transactions and complex read‑side solutions.

Two Main Solutions

The article presents two mainstream techniques for solving the distributed query problem: the API Composition Pattern and the CQRS (Command Query Responsibility Segregation) Pattern .

API Composition Pattern

In this pattern there are two roles:

Data Provider Service : a service that can supply part or all of the required data via its own API.

API Composer : a component that calls one or more data‑provider services, aggregates and transforms the results, and returns the final response.

Example: an online‑education scenario where a student‑side service needs to fetch data from preview, course, teacher, and homework services to render a timetable. The diagram below shows the data flow.

API composition is simple and developer‑friendly, but it struggles with complex queries that involve multiple service filters and result limits. For instance, retrieving ten orders where the product category is "fresh" and the user level is "VIP" would require multiple sequential calls and extensive in‑memory filtering, leading to performance bottlenecks.

CQRS Pattern

CQRS separates read and write responsibilities. Read models are built as materialized views, often stored in a search engine such as ElasticSearch . Data synchronization from the source services can be achieved via double‑writes in code or by using Alibaba Canal to capture binlog changes.

Using the same e‑commerce example, the product, order, and user services continuously sync their data to ElasticSearch, forming a wide table that can be queried directly for "fresh" products belonging to "VIP" users. The query becomes a single ElasticSearch request:

POST /_search?from=0&size=10
Content-Type: application/json
{
  "query": {
    "match": {
      "user_level": "VIP",
      "category": "fresh"
    }
  }
}

The CQRS approach offers significantly higher query performance because the heavy filtering and joining are performed offline during data synchronization, not at request time.

Comparison and Trade‑offs

API Composition : easy to implement, fast development, but may cause high memory usage and latency for complex filters.

CQRS : superior read performance and scalability, but introduces additional components (Canal, ElasticSearch, a dedicated query service), increasing system complexity and hardware cost. Data propagation adds latency (ElasticSearch refresh interval is typically 1 second, and Canal adds its own delay).

Conclusion

The author recommends starting with the API composition pattern because of its lower entry barrier; if it cannot meet the requirements, then consider migrating to CQRS despite its higher operational overhead. Additionally, the article cautions against forcefully refactoring a comfortable monolith into micro‑services merely for trend reasons.