들어가며이번 시간에는 콘서트 예약 서비스의 성능을 개선하기 위해 현재 시나리오의 조회 API 중 캐싱을 적용할 부분에 대해 고민해 보고, 기존 RDB에서 작동되고 있던 대기열 로직을 Redis로 이관하는 과정에 대해 살펴보겠습니다. 또 캐싱 전후 테스트 결과 비교를 통해 얼마나 성능이 개선되는지도 체크해 보도록 하겠습니다.    캐시 적용 기준우선 캐시를 적용할 때 고려해야 할 기준은 아래와 같습니다. 1. 조회 비용이 높은지데이터베이스에서 데이터를 조회하는 비용이 큰 경우 캐싱을 통해 성능을 개선할 수 있습니다. 2. 얼마나 자주 조회되는지반복적인 요청이 많은 경우 캐시를 활용하여 효율성을 높일 수 있습니다. 3. 데이터 정합성에 이슈가 없는지캐시를 사용할 경우, 캐시된 데이터와 원본 데이터 간의 정합..

들어가며콘서트 예약 서비스와 같은 애플리케이션에서는 동시성 처리를 고려해야 합니다. 좌석 예매 오픈 시 여러 사용자가 동시에 예약을 시도하면, 자원이 안전하게 관리되지 않을 경우 예약이 초과되거나 데이터 일관성이 깨질 위험이 있습니다. 이번 시간에 코드 적용 및 테스트를 통해 각 동시성 처리 방식의 장단점을 검토하고, 최종적으로 비즈니스 로직에 적합한 동시성 처리 방식을 선정해보겠습니다.  동시성 이슈가 발생할 수 있는 비즈니스 로직이 서비스에서 동시성 이슈가 발생할 수 있는 주요 로직은 아래와 같습니다.좌석 예약락을 걸어야 하는 자원seat테이블의 statusconcert_schedule테이블의 available_seats포인트 충전 및 결제락을 걸어야 하는 자원user테이블의 balancereserv..