문제
회원 개인정보를 조회하는 경로가 여러 시스템에 흩어져 있어, 메시지를 보내는 사내 시스템이 항목마다 다른 경로로 조회해야 했습니다.
그래서 문제를 “항목마다 다른 조회 경로를 표준 조회 API 계약으로 모으는 것”으로 정했습니다.
접근
- 조회 API 설계는 ADR과 HLD로 정리했고, 같은 주에 메시지 플랫폼의 구현 수준 아키텍처 결정과 조회 일원화 API 결정을 ADR로 따로 남겼습니다.
- 휴면 회원 이메일 발송과 휴면 회원 정보 이전은 별도 ADR로 함께 썼고, 휴면 회원 처리 방식은 배치에서 API를 부르는 방식, 이벤트를 받아 처리하는 방식, DB를 직접 조회하는 방식을 비교했습니다.
결정
- 흩어진 조회 경로를 표준 조회 API로 모으는 설계를 ADR과 HLD로 확정했습니다.
결과
- 조회 일원화 설계를 ADR과 HLD로 확정해, 휴면 회원 처리처럼 개인정보 규정이 얽힌 기능이 같은 조회 계약을 쓰는 기반을 만들었습니다.
기록과 자동화
- 문서: 조회 일원화 ADR과 HLD, 메시지 플랫폼 구현 수준 결정 ADR, 휴면 회원 처리 ADR을 남겼습니다.