왜 필요한가

경계가 분명한 업무들이 서로 다른 일정과 책임으로 배포되어야 합니다. 한 번에 묶인 배포는 무관한 변경까지 조율하게 만듭니다.

어떻게 해결하는가

  1. 가상 독서 앱: 한 팀, 카탈로그·보관함·결제 각각 v1. A17은 태그 없음.
  2. 호환되는 태그 기능을 보관함 v2로만 배포합니다. 카탈로그·결제는 v1 유지.
  3. 보관함이 네트워크로 카탈로그를 조회한 뒤 자체 저장소에 travel을 기록합니다. 쓰기 전 조회 시간 초과 시 태그 없음 유지. 실패를 알리고 복구 후 재시도합니다.
독립 배포와 함께 다뤄야 할 원격 장애

설명을 위한 가상 예시

기능 하나만 독립 배포

독서 앱 · 한 팀 · A17은 태그 없음

변경: 보관함 태그 추가. 결제 동작은 그대로.

호환 계약 유지: 보관함만 새 배포 필요.

  1. 배포 단위 · 1

    카탈로그

    v1 → v1

    동작 유지

    자체 저장소카탈로그

  2. 배포 단위 · 2

    보관함

    v1 → v2

    태그 기능 추가

    자체 저장소보관함

  3. 배포 단위 · 3

    결제

    v1 → v1

    동작 유지

    자체 저장소결제

네트워크 조회 · 태그 쓰기 이전

보관함 → 카탈로그 API

원격 응답은 보장되지 않습니다. 결제는 이 조회 경로에 참여하지 않습니다.

  1. 1 · 성공

    조회 성공 → travel 기록 → A17 태그는 travel.

  2. 2 · 카탈로그 조회 시간 초과

    쓰기 전 조회 실패 → 태그 없음. 실패 안내, 복구 후 재시도.

각 서비스가 데이터를 소유하며 다른 서비스 테이블을 직접 읽지 않습니다. 독립 배포에도 관측·장애 처리가 필요하며 의존 서비스의 장애가 전파될 수 있습니다.

소유권 상자는 접근 규칙을 뜻하며 데이터베이스 서버 수를 뜻하지 않습니다.

무엇이라 부르는가

마이크로서비스는 명시적 계약과 데이터 소유권을 갖고 독립 배포하는 업무 기능별 서비스입니다. 프로세스를 나누기만 해서는 독립성이 생기지 않습니다. Lewis·Fowler

네트워크 장애와 서비스 간 데이터는 조율해야 합니다. 나머지 기능은 모듈러 모놀리스로 유지할 수 있습니다.