monolith
초기 복잡도 낮음
강한 트랜잭션, 작은 팀, 빠른 기능 변경이 우선이면 단일 앱이 더 낫다.
마이크로서비스는 분리가 아니라 계약 설계다
서비스를 프로세스로 나누면 호출은 네트워크 메시지가 된다. 그래서 NestJS 마이크로서비스는 경계, transport, 실패 처리, 관측 기준을 한 세트로 판단해야 한다.
분리 여부를 먼저 고르는 기준
monolith vs serviceservice
책임과 배포 독립
주문, 결제, 알림처럼 변경 이유와 확장 단위가 다르면 후보가 된다.
contract
통신 실패를 포함
timeout, retry, 중복 메시지, 추적 id까지 계약에 포함해야 운영된다.
서비스를 나눌 때 고정할 4가지
decision matrix1. 경계
업무 소유권
누가 이 데이터를 만들고 바꾸는지 한 서비스로 닫는다.
피해야 할 상태
여러 서비스가 같은 DB 테이블을 직접 읽고 쓴다.
2. 통신
동기 호출
즉시 결과가 필요하면 TCP, HTTP, gRPC 호출을 사용한다.
비동기 이벤트
후속 처리와 느슨한 결합이 필요하면 Kafka 같은 broker를 둔다.
3. 실패
시간 예산
호출마다 deadline과 fallback을 정해 장애 전파를 끊는다.
중복 처리
재시도와 event replay가 같은 결과로 수렴하도록 만든다.
4. 운영
추적 연결
trace id, request id, queue lag로 서비스 사이 흐름을 이어 본다.
배포 계약
schema version과 호환성 규칙을 두고 소비자를 먼저 보호한다.