
프로젝트 설계
서비스에서는 사용자가 특정 가게 상세 조회 페이지에 진입하면 해당 가게의 조회수가 증가하고, 페이지를 벗어나면 감소하는 동적 기능이 필요합니다. 이를 위해 여러 통신 기술(SSE, WebSocket, RabbitMQ, Kafka)을 고려하였으며, 각 기술의 장단점을 아
프로젝트 배포 파이프라인을 구축할 때, Jenkins와 GitHub Actions 두 가지 옵션을 검토했습니다. 여러 측면에서 비교한 결과, GitHub Actions를 선택한 주요 이유는 다음과 같습니다.GitHub Actions:GitHub Actions는 GitH
🟩장점다양한 결제 수단 지원💳 : 신용카드, 가상계좌, 계좌이체, 휴대폰 결제 등 다양한 결제 옵션을 제공API 안정성 높음🔒 : 오랜 기간 운영된 PG사인만큼 장애 발생 가능성이 적음정기 결제 & B2B 기능 제공📅🔄 : 정기 결제, 자동 결제 같은 고급 기
초기에는 엑세스토큰만을 사용하여 로그인을 관리했는데, 엑세스토큰의 만료 시간이 짧아 사용자가 자주 로그인을 다시 해야 하는 불편함이 발생했습니다.즉, 사용자가 로그인한 후에도 짧은 시간마다 토큰 만료로 인해 인증이 끊기고, 다시 로그인을 해야 하는 상황이 문제였습니다.
SSE (Server-Sent Events)를 React 애플리케이션에 적용하면서 발생한 문제들과 해결 방법을 정리SSE를 알림기능에 사용하기 위해 전역 페이지에 적용함.SSEProvider가 App.js의 Router 전체를 감싸고 있어 로그인/회원가입 페이지에서도

데이터 수가 증가함에 따라 현재 Store 엔티티와 연관된 검색 기능에서 성능 문제가 발생하고 있습니다.searchStoreQuery 메서드에서 다수의 조인과 조건 필터링이 이루어지며 응답 속도가 저하됩니다. 이로 인해 사용자가 검색 결과를 확인하는 데 시간이 오래 걸
초기 구현에서는 데이터베이스에서 직접 쿼리를 수행하여 "실시간 웨이팅 순서"를 계산했습니다.예를 들어, 아래와 같이 특정 가게와 날짜, 그리고 본인의 웨이팅 번호보다 앞에 있는 대기 중인 팀의 수를 DB에서 직접 카운트하는 방식입니다.문제점:DB 부하 증가: 실시간으로