[Server] 게시글 좋아요 수 조회 전략 : COUNT 쿼리 VS 반정규화
·
Server
시작하며게시글 목록을 불러올 때 각 게시글의 좋아요 수를 함께 보여주는 기능을 구현했습니다.좋아요 수를 보여줄 때 COUNT 쿼리를 통해 보여줄지, 테이블에 반정규화 컬럼을 집어넣어 보여줄지에 대한 저의 생각을 적은 글입니다.Redis나 Kafka 등의 기술 고려는 우선 제외했습니다. 서버 비용을 최대한 아끼고자 했고, 개발자 2명이서 시작한 프로젝트라 관리 비용을 최대한 줄이기 위해서입니다. 대규모 트래픽 상황에서의 대응 전략은 따로 글을 작성할 생각입니다.Post 도메인과 PostReaction 도메인전략을 설명하기 전에 프로젝트 도메인에 대해 간단하게 설명드리겠습니다.게시글(Post) 도메인과 게시글 리액션(PostReaction) 도메인이 존재합니다.@Builderpublic record Post..
[Server] 도메인 서비스(Domain Service)와 애플리케이션 서비스(Application Service)에 대한 고찰
·
Server
시작하며헥사고날 아키텍처를 기반으로 프로젝트를 진행하며, 도메인 서비스와 애플리케이션 서비스의 역할 분리에 대해 고민했습니다.이 글은 그 고민의 과정과 두 서비스를 분리하게 된 기준을 정리한 기록입니다. 개인적인 경험과 주관적인 견해가 포함되어 있어 정답이 아닙니다. 그저 저의 고민과 결론을 적어놓은 글입니다. 도메인 서비스 vs 애플리케이션 서비스도메인 서비스(Domain Service)는 도메인 로직을 수행하지만, 특정 엔티티에 넣기에 애매한 로직을 다룰 때 사용됩니다.반면, 애플리케이션 서비스(Application Service)는 도메인 영역을 바라보며 트랜잭션, 영속성 처리, 외부 통신 등을 담당하고 전체적인 흐름을 제어하는 역할을 합니다. 이 두 서비스의 가장 큰 차이점은 도메인 로직의 유무입..
[Server] 신뢰성 확보 WITH Transactional OutBox Pattern
·
Server
안녕하세요, 절박한 개발자입니다.이번 글에서는 MSA(Microservices Architecture) 환경에서 서버 간 이벤트를 어떻게 처리했는지, 그리고 오류 발생 시 어떤 전략을 사용해 문제를 해결했는지에 대해 공유하려 합니다. 그럼, 본격적으로 시작해보겠습니다.프로젝트 프로세스판매자는 애완견 관련 상품을 등록하고, 구매자는 자체 페이 서비스인 ‘멍페이’(카카오페이와 유사)를 이용해 안심결제 또는 계좌 이체로 상품을 구매할 수 있습니다.구매자는 안심결제를 통해 물건을 안전하게 받은 후 '구매 확정' 버튼을 누릅니다. 그러면 중고 물품 서비스에서 해당 상품이 '거래 완료' 상태로 변경되고, 이벤트가 발행되어 페이 서비스가 안심 결제 수수료를 제외한 금액을 판매자에게 입금합니다.메시지 발행 실패앞서 말..
[Server] 멱등성 보장
·
Server
이번 글은 제가 프로젝트에서 페이서비스를 담당하며 충전,환전,결제등등 중요한 API를 다루며 고민했던 멱등성을 어떻게 보장할지, 하나의 트랜잭션을 어떻게 안전하게 처리할지 고민했던 내용과 해결했던 방법에 대해 적어보고자 합니다.멱등성이란?멱등하다는 표현은 개발자라면 언제 한번쯤 들어본적이 있을겁니다.멱등하다는 것은 하나의 작업을 수행한 뒤 여러 차례 적용해도 결과를 변경시키지 않는 작업 또는 기능의 속성을 의미합니다.멱등한 작업의 결과는 한번 수행하든 여러번 수행하든 같습니다.멱등한 API멱등한 API도 똑같습니다. 두 번 이상 여러변 요청해도 결과는 처음 요청과 똑같이 돌아옵니다.단순히 값만 같은게 아닌 서버 상태(DB)에도 영향을 미치지 않습니다.사용자가 안심하고 서비스를 이용할 수 있도록 만들게 합..
[Server] 조회 쿼리 개선
·
Server
조회 쿼리 성능 개선, 어디서부터 시작할까?서비스의 규모가 커질수록 데이터베이스 쿼리 성능은 점점 더 중요한 요소가 된다. 특히, 대량의 데이터를 조회하는 경우 성능 저하가 사용자 경험에 직접적인 영향을 미칠 수 있다. 현재 진행 중인 프로젝트에서도 여행사 ID로 제안받을 수 있는 계획서를 조회할 때, 기대만큼 빠른 응답 속도를 얻지 못하고 있다. 쿼리 실행 시간이 만족스럽지 않은 상황에서, 백엔드 개발자가 어떻게 최적화를 하는지 천천히 알아보고자 한다.문제 분석현재 데이터베이스에는 약 1000만 개의 여행 계획 데이터가 저장되어 있다. 하지만 아직 인덱스나 기타 최적화 작업이 전혀 적용되지 않은 상태다. 즉, 아무런 성능 개선 없이 원초적인 형태의 데이터 조회가 이루어지고 있다. 이런 환경에서 CONF..