comment_v2에서 unique index 를 추가하지 않고 table 생성 시 path에 unique 제약을 걸어도 효과가 같을까요?

kkasten님, 안녕하세요! 잘 수강해주셔서 감사합니다!둘다 동일하게 유니크 인덱스를 만들어주는 것입니다.테이블에 유니크 제약을 정의한다면, 인덱스를 따로 만들 필요 없습니다!

hot article 로직 변경

태우님, 안녕하세요!영구 저장이면 굳이 인메모리 데이터베이스에 저장할 필요는 없을 것 같습니다.백업 기능도 제공하긴 하지만, 비용이나 운영 복잡도 등 고려하면 그냥 안전한 저장소에 저장하고 레디스는 캐시로 활용하면 충분할 것 같네요.

MSA -> 모놀리식 패턴으로 수정

태우님, 안녕하세요!모놀리식에서는 굳이 동일한 데이터를 복제해서 저장할 필요는 없을 것 같네요.각 서비스의 리포지토리에서 count 가져와도 충분할 것 같습니다!

MSA 에서 Monolithic Architecture로 마이그레이션

태우님, 안녕하세요!모놀리틱으로 변경한다면, 말씀하신대로 분리되어있는 각 마이크로서비스 모듈을 패키지 분리하면 충분할 것 같네요!common 모듈은 지금처럼 분리해둬도 딱히 문제는 없습니다.필요한 의존성들이 단일 애플리케이션에서 실행된다는 점만 인지해주시면 될 것 같습니다.강의 잘 수강해주셔서 감사합니다!

각 application.java에서 빈 스캔할때 차이

닉네임무얼하지님, 안녕하세요! 말씀 주신 사항만으로는 저도 정확한 원인 파악은 어렵지만, 짐작가는 부분 남겨봅니다! 강의에서는 애플리케이션에서 다른 패키지 모듈의 빈을 스캔하기 위해서 AutoConfiguration을 사용 중 인데요,outbox-message-relay > resources 디렉토리 > META-INF 디렉토리 > spring 디렉토리에서,org.springframework.boot.autoconfigure.AutoConfiguration.imports 파일을 정의하고,kuke.board.common.outboxmessagerelay.MessageRelayConfig자동으로 스캔하기 위한 Configuration 클래스를 선언하고 있습니다. 많이들 실수하시는 부분이,META-INF 디렉토리 하위의 spring 디렉토리인데, META-INF.spring 디렉토리로 선언하기org.springframework.boot.autoconfigure.AutoConfiguration.imports 파일명에서 오타kuke.board.common.outboxmessagerelay.MessageRelayConfig 에서 오타MessageRelayConfig에서 @ComponentScan("kuke.board.common.outboxmessagerelay") 스캔 범위 잘못 지정하거나 오타등이 있더라고요. 혹시 위 내용들 점검해보시겠어요?

섹션4 (좋아요)의 댓글 수 구현 강의에서 질문 있습니다.

태우님, 안녕하세요! 강의에서 제시한 요구사항에서는 논리적 삭제한 댓글도 "삭제 댓글"이란 상태로 사용자에게 나타나기 때문입니다.사용자가 내용은 볼 수 없지만, 아무튼 그 공간을 차지하고 있기 때문에 카운트에 포함되는게 적절하다고 판단 했네요!정책은 그냥 정하기 나름일 것 같습니다!

ArticleDeletedEventHandler

성장하자님, 안녕하세요! ArticleQueryModel 모델에 좋아요 수, 댓글 수도 모두 포함되어 있습니다.ArticleQueryModel을 삭제하면, 해당 데이터도 당연히 함께 삭제됩니다! 조회 수는 캐시 TTL에 의해 자동으로 제거됩니다. 굳이 실시간으로 지울 필요는 없습니다.특히 참조 데이터 지우는 작업들이 많고 무거울수록 실시간으로 한번에 처리하는 일은 드물고, 그럴 필요도 없습니다.어차피 진입점을 막으면 데이터 접근도 불가하고, 사용성에 문제가 생기지도 않습니다.트래픽이 적은 시점 또는 필요한 보관 기간이 끝난 시점 등 안전한 상황에 별도 배치나 스케줄링으로 데이터를 정리할 수도 있습니다.

TransactionalEventListener 관련 문의드리고자 글 남깁니다.

자기개발하고싶어요님, 안녕하세요! payload(강의에서는 OutboxEvent) 를 통해 분기처리하는 방법만 보이다보니제가 보기엔 이게 가장 깔끔하고 편할 것 같은데, 굳이 다른 방법을 찾으시는 이유가 있을까요?파라미터 타입이 다르면 호출이 되지 않는데, 어떠한 부분에서 불필요한 리소스 사용이라고 느끼셨을까요? 다른 구현 방법으로는,@TransactionalEventListener의 condition 필드를 사용해서 분기 조건을 만들 수도 있고,단일 리스너에서 직접 분기 코드를 작성할 수도 있습니다.직접 원하는 부분에만 커스텀 애노테이션을 만들어서 AOP를 적용시킬 수도 있고요. 다만, 그냥 파라미터 타입만 달리해서 구현을 하는게 가장 간단하고 편할 것 같네요!

오타 문의

감스트의웃음노예님, 안녕하세요! 앗, 말씀 주신 부분이 맞네요. 테이블을 쪼갠 것이므로 비정규화가 아니라 정규화가 맞습니다.이 부분 추후에 수정할 수 있도록 하겠습니다!제보 감사합니다!

406 Not Acceptable에러 발생

Gwangseok Lee님, 안녕하세요! 말씀 주신 내용으로는 파악하기가 어렵네요. Accept와는 무관할 것 같습니다.컨트롤러 코드도 보여주시겠어요?@RestController로 선언되어 있는지, @PostMapping으로 잘 선언된게 맞는지 확인해보시면 좋을 것 같네요!