그러면 너무 작은 서비스는 어떨까?
• 문제 도메인의 한 부분에 속한 마이크로서비스가 토끼처럼 번식한다: 모든 것이 마이크로서비스가 되면 서비스에서 비즈니스 로직을 구성하는 것이 복잡하고 어려워진다. 작업을 완료하는 데 필요한 서비스 수가 엄청나게 증가하기 때문이다. 흔한 징후는 애플리케이션에 수십 개의 마이크로서비스가 존재하고 각 서비스가 하나의 데이터베이스 테이블과 통신할 때 나타난다.
• 마이크로서비스가 지나치게 상호 의존적이다: 문제 영역의 한 부분에 속한 마이크로서비스가 하나의 사용자 요청을 완료하려고 계속 서로 호출하고 있다는 것이 발견된다.
• 마이크로서비스가 단순한 CRUD(Create, Read, Update, Delete) 서비스 집합이 된다: 마이크로서비스는 비즈니스 로직의 표현이 데이터 소스의 추상화 계층이 아니다. 마이크로서비스가 CRUD 관련 로직만 수행한다면 너무 세분화된 것일 수 있다.
마이크로서비스 아키텍처는 처음부터 올바른 설계를 얻기가 어렵기 때문에 진화적 사고 프로세스로 개발되어야 한다. 그러므로 첫 서비스들을 잘게 나누기보다 크게 나누어서 시작하는 것이 더 좋다.
독단적 설계를 하지 않는 것도 중요하다. 서비스에 물리적 제약이 있을 수 있다. 예를 들어 두 개별 서비스 사이에 너무 많은 호출이 발생하거나 서비스의 도메인 경계가 명확하지 않다면 데이터를 조인하는 집계 서비스를 만들어야 한다. 끝으로 완벽한 설계를 얻고 싶어 시간을 낭비하고 노력에 비해 아무것도 보여 주지 못하는 것보다 실용적 접근 방식을 취해 설계를 전달하자.