요구사항

• 고객이 전송 버튼을 누르면, 외부 알림톡 전송 API 에 요청을 보내야 함
• 전송상태가 실시간으로 반영되면서 지속적인 외부 API 와의 상호작용이 필요함

문제사항

• 프론트엔드에서 바로 알림톡 요청을 보낼지, 혹은 백엔드를 거쳐 알림톡 요청을 보낼지 통제권을 어디에 두어야 할지
• 외부 API 에서 받아온 값을 바로 프론트엔드에 보내 주고 DB에 저장할지, 혹은 외부API응답값을 DB에 저장한 뒤 프론트엔드 요청에 대한 응답으로 반환할지

해결방향

• 시퀀스 다이어그램을 통해 각각의 장단점을 비교 분석

• Redis를 통해 자주 변하는 데이터를 저장해두고 비교적 변하지 않는 값을 DB에 저장하는 형태로 쿼리 요청을 최소화

의견결정

• 전송 상태만을 위해 Redis 서버를 만들긴 어렵기 때문에 ElastiCache를 통해 서버 관리 로드를 축소
• axios를 활용한 리다이렉트로 자체 로직과 외부 요청이 순차적으로 진행되도록 처리

요구사항

• 고객이 알림톡 버튼을 누르면, 로그 데이터가 생성되는 식으로 클릭률을 트래킹 시도
• 알리고 전송 API를 보내기 전에, 회원이 입력값 URL 을 redirect 최종 경로로 등록하기 위해 우리측에서 식별 가능한 값을 미리 만들어 URI를 심어야 함

문제사항

• 어떤 값을 식별자로 사용할 것인가 - 각 엔티티마다 가지고 있는 ID를 포함하는 임시 uuid
• URL 에 쿼리, 파라미터, 별도의 식별자 중 어떤 형태로 식별 값을 넣을 것인가
• 해당 식별 값에 어떤 데이터베이스를 활용해야 할 것인가

해결방안

• MySQL : 각 테이블마다 관계가 이미 일관되고 JOIN 등으로 여러 테이블을 참조해야 하기 때문에 응답 시간 및 복잡도가 늘어남
• Redis : 세션 Id 처럼 해당 값을 키:값 형태로 저장할 수 있는 가벼운 NoSQL 데이터베이스
• MongoDB : 식별값만 저장해야 하기 때문에, 해당 목적만으로 적용하기엔 무겁다고 판단

의사결정

• 전송 전 / 전송 / 결과 조회 등의 여러 이벤트 흐름마다 해당 키의 값을 업데이트 해야 하기 때문에 빠른 조회가 가능한 인메모리 데이터베이스 채택

요구사항

• 소스 코드 변화가 있을 때마다 배포를 위해 단순 반복 작업을 수행하는 것에 대한 비효율성

해결방향

• Jenkins : 다양한 기능을 제공하나, 단기간에 숙달하기에는 필요한 사전 지식이 많이 필요
• Github Action : GitHub과 통합된 환경을 제공하고 사용이 빠르고 쉬움

의사결정

• 초기 인프라 구축에 시간을 최소화하는 것이 기능 개발 시간을 효율적으로 사용할 수 있다고 판단.
• 배포 자동화를 단기간에 진행하기 위해 빠르고 어렵지 않게 다룰 수 있는 Github Action으로 선택

문제사항

• 그룹 전체 목록에서 그룹에 속하지 않은 고객들이 조회되지 않아 인원수 차이가 발생함

해결방향

• ERD 및 정책 변경 : 모든 클라이언트들은 그룹에 속하도록 처리
• 정책 유지 및 API 변경 : 그룹 미지정 클라이언트들만 따로 DB에서 조회하여 전체 조회 API 에 추가

의사결정

• 서비스 정책을 변경하는 것이 API 확장성과 복잡도에 비해 시간과 노력이 덜 듦
• 우리가 원하는 것은 ‘그룹 미지정’ 이라는 개념이기 때문에 그룹의 형태를 차용하기로 함.

개선 및 보완

• 최초 회원가입시 미지정 그룹 생성
• 그룹을 등록 안하는 고객 대량 생성, 고객 단건 생성 할 때 자동으로 미지정 그룹에 저장되도록 구현
• 같은 이름의 그룹이 존재할 경우 ‘그룹명(숫자)’ 형태로 추가되도록 변경