상품 조회 서비스
다양한 방식의 상품 조회 서비스를 제공하려고 한다. 먼저 인기순, 최신순 정렬 상품 조회와 마감 임박 상품 조회 서비스를 구현할 예정이다.
Spring Batch + Scheduler
스프링 배치와 스케쥴러를 사용하여 상품 조회 서비스를 구현하는 중이다. 정렬된 상품을 보여주는 서비스가 실시간에 민감한 데이터가 아니며, 데이터가 다양한 위치에 있거나 테이블에 데이터가 많아져도 일정하게 빠른 조회 성능을 요구한다. 따라서 미리 주기적으로 데이터를 조회해 캐싱해 놓고 API Request에 대해서 이미 조회 및 정렬된 데이터를 반환하도록 설계하였다.
Cache DB로는 MongoDB를 사용한다. 트랜잭션이나 제약 조건들을 엄격하게 지켜야하는 데이터가 아닌 임시 데이터를 선형적으로 추가 저장하는 용도이기 때문에 적합하다고 판단하였다.
어차피 임시 데이터인데 왜 Redis와 같은 In-Memory DB를 사용하지 않고 MongoDB를 사용하였나?
MongoDB vs Redis - https://www.mongodb.com/compare/mongodb-vs-redis
처음에 In-Memory DB인 Redis에 조회 데이터를 넣어놓고 계속 최신 데이터로 업데이트하려고 하였다. 하지만 In-Memory DB인 만큼 메모리를 잡아먹는 것이 부담이라 판단하였다. 현재 계획은 세 가지 아이템 조회 방식뿐이지만, 다양한 아이템 조회 방식들이 추가된다고 하였을 때 In-Momory DB는 적합하지 않다고 생각하였다. 따라서 Disk에 저장하는 MongoDB를 사용하기로 결정하였다.
Service Discovery & API Gateway에 서비스 등록
상품 서비스를 Serivice Discovery과 API Gateway에 상품 서비스를 등록을 진행하였다. 팀원이 초기 설정한 부분과 컨벤션에 최대한 맞추어 등록하였다.
TODO
Kafka를 적용한 알림 서비스를 구현할 예정이다. 알림 이벤트 발생시키는 곳에서 비동기로 알림을 누적하고 알림 서비스는 MQ에 누적된 알림을 처리하는 방식을 현재 구상중이다.
Kafka를 사용해본 적이 없어 학습이 선행되어야 한다.
클라이언트와 알림 서비스 간의 통신은 단순하게 주기적 polling으로 구상하고 있다. 모바일과 웹 모두 간단하게 구현가능하기 때문이다. 나중에 websocket 프로토콜이나 push 알림, 이메일 알림 등을 고려할 예정이다.
인기순 정렬 조회 서비스는 주문 서비스 구현하는 팀원과 상의 후에 추가 구현할 예정이다.
