@Setter 어노테이션과 @requiredargsconstructor 어노테이션 요구사항 분석하여 final 불변객체로 사용하기를 권장
(회원전용 서비스, 실시간 온라인 경매 채팅)

• 참고: @RequestBody에서는 Setter가 필요 없을까? / 불변객체의 장단점

• LoginDto 코드 사용 부분에서 클린(Clean)하지 않은 방향으로 데이터 전달하고 있음.
• 적용 가능한 디자인 패턴: Searching

• 성능 이슈로 인한 회원가입 후 인증 메일 발송 비동기 처리

Based on @f-lab-hubert PR comment:

지금은 restTemplate 생성시 default값으로 설정을 초기화 하지만 실제 운영에 사용될때는 중요 설정값을 잘 살펴보고 설정해주어야합니다. 예를들어 connectionPoolSize, connectionTimeout, readTimeout 같은 값들이 그 중 하나 일 것 같아요 :)

• ref: https://e2e2e2.tistory.com/15

• DB와의 데이터 정합성을 위한 최적의 캐싱 전략 적용 필요 👩‍🚀

선택한 전략:

• 채팅 서비스 : 🆗
  • Write-Around 전략
• 결제 서비스 : ❌
  • Redis 사용 안함

• 현재 코드는 DBMS 종속적인 코드. 만약, DBMS 제품을 바꾸게될 경우 소스코드를 수정해야하는 번거로움이 생김(결합도가 높고 응집도가 낮은 상태)
• 적용 가능한 디자인 패턴: Adaptor 패턴 💊

• Java DTO 객체에서 필드값으로 Java.Time 혹은 Java.Date API 객체를 사용할 경우, Json 직렬화 이슈로 인하여 MySQL에서 해당 타입을 TIMESTAMP 타입으로 인식하지 못하는 이슈 발생.

🔑 온라인 경매 서비스 및 결제 서비스 웹 URL 접근 권한 수정(로그인 시, 이용 가능할 수 있도록 권한 설정 필요)

불필요한 어노테이션 삭제 및 코드 리팩토링 e.g.) @BeforeEach

• Redis Day 발표 자료에서 공유한 확연한 성능 차이로 인한 클러스터링 작업
• ❗포인트는 단순 클러스터링으로 노드를 추가해봤자 메시지 처리량이 증가하지 않음. Service Directory 노드로 살아있는 발행-구독자를 먼저 찾은 다음 그 수에 맞게 Redis 클러스터링 노드를 통해 메시지를 브로드캐스팅해야 처리량이 증가함