프로젝트 회고

사이드 프로젝트를 진행하면서 채팅 기능을 담당하게 되었다.채팅 기능에 대한 요구사항1:1 채팅 서비스채팅방 별 채팅 기록 저장프로젝트에서 사용할 기술에 대해 회의를 진행하면서 외부 브로커를 사용하기로 결정하였다. 왜냐하면, 프로젝트의 인프라 환경은 단일 서버이지만, 채

성능 테스트 진행 중 커버링 인덱스를 통해 성능을 개선한 사례를 정리해보려고한다. 성능 개선에 대한 내용을 정리하기 전, 테스트 진행 할 기능에 대한 설명을 작성해보려고한다.해당 프로젝트는 투표형 커뮤니티로 게시글 생성 시, 게시글의 내용과 투표에 대한 설명글을 따로

이번 글은 게임 전적 사이트 프로젝트를 진행하면서 성능 최적화하를 위해서 SQL 튜닝한 내용을 정리하기 위해 작성해보려고한다.SQL을 튜닝한 부분은 방명록을 조회하는 기능이었다. 서비스 요구사항에는 유저를 검색하거나 유저의 전적을 확인하면 방명록을 보여주어야한다. 아래

프로젝트를 진행하는데 있어서 회원가입 시 이메일 인증 기능을 구현하게 되었다.이메일 인증을 구현하기 위해서 구글 SMTP를 이용하여 구현하였다. 이처럼 구글 SMTP는 구글 서버에서 제공되는 서비스이기 때문에 외부 API를 호출하는 것과 같다. 또한 구글 SMTP 서비

프로젝트를 진행하면서 UX경험을 향상 시키기 위해서 무한 스크롤 방식을 도입하였습니다.하지만, 백엔드 API는 Offset 기반의 페이지네이션으로 구현되어 있었습니다. 하지만 Offset기반의 페이지네이션은 데이터 중복 문제가 발생한다는 것을 알게 되었다.

데이터 중복 문제로 UX가 저하되는 오프셋 기반 페이지네이션을 커서 기반 페이지네이션으로 리팩토링했습니다.UX측면 뿐 아니라, 성능적인 측면에서는 얼마나 차이가 나는지 성능 테스트를 진행해보려고합니다.

이전에 프로젝트를 진행할 때는, 구현 코드를 작성하고 테스트 코드를 작성하지 않았었습니다.하지만 이번 프로젝트에서는 Controller, Service, Repository, Entity 모든 계층에서 단위 테스트를 진행하였습니다. 그리고 단위 테스트 코드를 작성하면서

이전의 무한 스크롤 방식에서 데이터 조회 시, 중복 현상 이슈를 해결하기 커서 기반 페이지네이션을 도입하였습니다. 이러한 커서 기반 페이지네이션을 적용하여 데이터 중복 이슈 뿐 아니라, 기존의 오프셋 기반 페이지네이션의 한계점인 오프셋이 값이 커질 경우에도 빠른 성능을

회사에서 Outbox 패턴으로 이벤트를 처리하는 배치 모듈을 만들고 있었는데,Lock wait timeout exceeded; try restarting transaction (SQL Error: 1205) 에러를 만났다...주문 생성 -> 주문 생성 Outbox 이벤

최근 소프트웨어 아키텍처에 대해 관심이 생겼고, 도메인 주도 개발 개념을 접하게 되었다. 도메인 주도 개발은 단순한 개발 방법론이 아니라 소프트 웨어로 해결해야하는 문제 영역(비즈니스 도메인)을 깊이 이해하고 이를 코드로 구현해내는 것을 목표로한다. 이처럼 도메인 주도

미용실 예약 서비스를 만들면서 아래와 같은 핵심적인 요구사항이 있었다."같은 날짜 같은 시간에는 예약이 하나만 존재해야한다."위 요구사항을 구현하기 위해 "예약 생성 시 이미 예약이 있으면 막으면 되는거 아닌가?" 라고 쉽게 생각해 예약 생성 로직을 아래와 같이 구현했