마이크로서비스로 전환 시 분산 데이터 관련 문제는 트랜잭션 뿐 아니라 쿼리를 구현하는 방법도 있다. DB가 하나뿐인 모놀리식 애플리케이션에서는 비교적 쉽게 쿼리를 구현했다. 하지만 마이크로서비스 아키택쳐에서는 여러 DB에 분산된 데이터를 조회해야 하는데, 기존 분산 쿼리 매커니즘은 기술적으로 가능해도 캡슐화에 위배되기에 부적절하다.
마이크로서비스 아키택쳐는 다음 두 패턴으로 쿼리를 구현한다.
모놀리식 애플리케이션은 전체 데이터가 하나의 DB에 있어 여러 테이블을 조인해서 주문 내역을 조회하면 되지만 마이크로서비스 아키택쳐로 전환하면 데이터가 여러 서비스에 흩어진다. 따라서 클라이언트가 모든 관련 서비스에 요청해야한다.
이 여러 서비스를 호출해 반환 결과를 조합하는 방법을 API 조합 패턴이라하고 다음과 같이 구성되어 있다.
이 패턴으로 특정 쿼리 작업을 구현할 수 있을지는 데이터의 여러 요인에 따라 가변적이다. 대부분의 경우는 이 패턴을 적용하여 쿼리 작업을 구현할 수 있다. 주문 애그리거트의 상세 정보를 쿼리한다고 하자. 클라이언트는 API 조합기의 REST endpoint로 요청을 보낼 것이다(gRPC 등 다른 IPC도 같은 개념). GET /order/{orderId}가 구현된 API 조합기는 해당 id로 각 관련 서비스를 호출한 후 수신응답을 EQUI 조인한다. 각 프로바이더 서비스는 애그리거트 하나에 해당하는 응답을 반환한다.
분산 시스템에서 쿼리 작업의 반응 시간을 최대한 줄이려면 가능한 한 API 조합기가 프로바이더를 병렬 호출해야한다. 하지만 동시에 병렬 호출할 수 있는 서비스가 아닌 의존 관계가 있어 순차 호출해야하는 경우도 있다. 이때 순차/병렬이 뒤섞인 호출을 성능/확장성이 우수하게 실행하려면 RxJava와 같은 리액티브 설계기법을 동원하는 것이 좋다.
API 조합 패턴의 단점은 다음과 같다.