이론적으로, 클라이언트는 각 개별 microservice에 직접 요청할 수 있다. 각각의 microservice는 public endpoint(https://serviceName.api.company.name)를 가지고 있다. 이 URL은 이용할 수 있는 인스턴트들에 요청을 분산처리하는 microservice의 로드밸런서와 맵핑된다. 상품 상세 정보를 얻기 위하여, 모바일 클라이언트는 위에 나열된 각각의 service들에게 요청할 것이다.

불행하게도, 이 옵션에는 여러 가지 도전과 제한이 있다. 한가지 문제는 클라이언트의 필요와 각 microservice에 의해 노출된 잘 나누어진 API사이의 부조화다. 이 예제에서 클라이언트는 7개의 분리되어 있는 요청을 해야만 한다. 더 복잡한 어플리케이션에서는 더 많은 요청을 해야만 할 것이다. 예를 들면, 아마존은 수백개의 서비스들이 상품 페이지를 다루기 위해서 호출된다. 클라이언트에서 LAN을 통해 수많은 요청을 할 때, public internet에서 너무 비효율적이 되고, 분명히 모바일 네트워크에서는 비현실적이다. 이러한 접근법은 클라이언트 코드를 훨씬 더 많이 복잡하게 할 것이다.

클라이언트가 microservice를 바로 호출하는 경우에 발생하는 또다른 문제는 웹 친화적이지 않은 프로토콜을 사용하는 경우이다. 한 서비스는 Thrift binary RPC를 사용하고, 또다른 서비스는 AMQP 메시징 프로토콜을 사용한다고 해보자. 둘 다 특히 브라우저 친화적이거나 방화벽 친화적인 프로토콜이 아니다. 그리고 내부적으로 사용하기에 가장 좋은 것도 아니다. 어플리케이션은 방화벽 밖에서 HTTP나 웹소켓과 같은 프로토콜을 사용해야 한다.

이러한 접근법의 또다른 약점은 microservice를 리팩토링하기 어렵다는 것이다. 시스템이 얼마나 서비스로 분할되었는지에 따라 우리가 변경하고자 할 때 시간이 걸릴 것이다. 예를 들어, 2개의 서비스를 통합하고자 하거나, 하나의 서비스를 2개 이상으로 나누고자 하는 경우가 있다. 그러나, 클라이언트가 직접 서비스들과 통신하고 있다면 이러한 종류의 리팩토링을 수행하는 것은 극도로 어려워질 수가 있다.

이러한 문제들 때문에 클라이언트에서 직접 microservice를 호출하게 하는 것은 전혀 이치에 맞지 않다.