'더 견고해지기 위해 남은 작업' 수업자료

노션 링크는 여기 있습니다~ https://www.inflearn.com/course/lecture?courseSlug=%EA%B2%AC%EA%B3%A0%ED%95%9C-%EA%B2%B0%EC%A0%9C-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%B6%95&unitId=215418

Payment Order 테이블 스키마

안녕하세요~ 방금 고쳤습니다.잘못된 내용에 대해 정정해주셔서 감사합니다.

'더 견고해지기 위해 남은 작업' 아 영상 파트에 나오는 자료 공유 받을수 있나요?

앗 놓치고 있었네요. 추가했습니다~ 마지막 수업 들으신 것 같은데 축하드립니다~ 고생 정말 많이하셨어요. 강의에 나왔던 부분들이 도움이 되셨길 바랍니다.

Ledger 및 Wallet 서비스에서 Kafka Consumer PaymentEventMessageHandler 에 typecast 문제가 발생됩니다.

안녕하세요~ 질문 남겨주셔서 감사합니다. 저도 이전에 이런 에러를 본 적이 있는데 직렬화 과정에서 에러가 나는 것 같아요. Spring MVC 의존성을 넣어주시면 될 것 같은데 한번 추가해 보실래요? Spring MVC 에 직렬화/역직렬화에 필요한 의존성이 들어가 있어서 이걸 추가하면 될 것 같습니다. 한번 추가해 보시고 안되면 말씀해 주세요~

다음 강의가 너무 기대되요:) 'Sacale-up 하며 배우는 대용량 트래픽 처리'

안녕하세요~ 질문 자주 남겨주시던 분이네요! 반갑습니다. Kotlin과 Spring Webflux라는 비주류 기술들 때문에 러닝 커브가 있으셨던 것 같아요. 불편함을 드려서 죄송하다는 말씀드리고 시작할게요. 처음에는 강의 제작할 때 Spring Webflux 정도는 기본 지식을 알려드릴까 했었는데, 하.. 이게 너무 강의가 이도저도 아니게 되는 느낌을 받아서 다 뺐거든요. 그래서 최대한 코드를 잘 작성하면 그래도 잘 이해하지 않으실까 생각했었는데 힘든 점이 많았을 것 같습니다. 다음에는 이런 니즈들을 이해해서 자바로 강의를 만들도록 할게요. Scale up 하며 배우는 대용량 트래픽 처리는 하자 않아요. 여러 문제로 계약은 취소했습니다.. 대신에 유의미한 다음 강의를 준비 중인데 기대해주세요. 세상에 없는 강의 준비 중입니다! 마이너한 주제는 아닐거에요. (+ 이전에 제 강의를 들어주셨던 분들에게는 최대한 할인을 해서 제공드릴 계획입니다.) 그리고 강의 들어주셔서 감사합니다!

강의를 듣고 문득 궁금한 점이 생겼습니다.

안녕하세요~ 질문 남겨주셔서 감사합니다. 궁금한 사항이 있으셨던 것 같은데 제 생각을 남겨볼게요. 1) 어니언 아키텍처가 아닌 핵사고날 아키텍처로 한 이유: 저는 어니언 아키텍처와 핵사고날 아키텍처가 크게 다르다고 생각하지는 않아요. 핵사고날 아키텍처가 조금 더 복잡할 순 있겠지만 외부 시스템과의 입출력 상호작용을 파악하기 더 쉽다라고 생각하기 때문에 사용했습니다. 장단점을 판단해서 자신에게 맞는 아키텍처를 사용하면 될 것 같습니다. 2) Webflux 를 사용한 이유: Spring Webflux 와 Spring MVC 를 비교했을 때 Webflux 가 좀 더 복잡한 프로그래밍을 요구하는 것 제외하고는 웬만해서는 MVC 보다 안정성 측면에서도 더 뛰어나다고 생각해요. 현재의 시스템은 서비스들이 마이크로서비스처럼 대부분 쪼개져있고 필요할 때 외부 통신을 하는데요. Spring MVC 와 같은 Synchronous Client 를 사용하게 되면 외부 서비스들이 장애가 나거나 요청이 안왔을 때 리소스가 점유당하는 문제가 생길 수 있습니다. 그에 반해서 웹플럭스와 같은 Asynchronous Client 는 하나의 이벤트 루프에서 최대 500개 까지의 Active Channel 을 맺을 수 있기 때문에 외부 서버의 장애에 클라이언트를 보다 보호해줄 수 있는거죠. 현재의 이 결제 시스템의 경우에는 외부 시스템과 상호작용하는 API 가 거의 없는데요. 카카오페이의 경우에는 수십개의 API 를 사용한다고도 합니다. 이 경우에는 Webflux 가 보다 안전할거에요. 도움이 되셨으면 좋겠습니다. 제 답변이 잘 와닿지 않는다면 다시 질문 주세요~

토스 개발자센터 들어가서 토스에서 지원하는 키 제공을 안해주네요...

안녕하세요~ 질문 남겨주셔서 감사합니다. 주말에 열심히 강의 들으시고 계신데 불편하셨을거 같아요. 이전에 나왔던 질문이라 답변한 적이 있어서 관련 링크 붙혀둘게요~ 해당 강좌 수업 노트에도 붙혀놓긴 했었는데, 인프런에서 강의에서 자주 하는 질문 리스트 이런 내용들을 볼 수 있는 페이지가 있으면 좋긴 하겠네요.. https://www.inflearn.com/questions/1253630/%ED%86%A0%EC%8A%A4-%ED%8E%98%EC%9D%B4%EB%A8%BC%EC%B8%A0-%EA%B2%B0%EC%A0%9C%EC%9C%84%EC%A0%AF-%EC%97%B0%EB%8F%99-api-%ED%82%A4-%EB%B9%84%ED%99%9C%EC%84%B1%ED%99%94

wallet service 구축에서 중복메시지 검증 로직이 필요한지 궁금합니다

안녕하세요~ 질문 남겨주셔서 감사합니다. 카프카 프로듀서에서 enable.idempotence=true 설정을 한다면 멱등성 프로듀서가 되서 중복 메시지는 발행안되는 건 맞습니다. 멱등성 프로듀서의 중복 메시지 제거 기법은 프로듀서 ID 와 메시지 Sequence Number 를 통해 중복을 제거하는데요. 중요한 건 프로듀서 어플리케이션이 새롭게 시작하는 경우 똑같은 프로듀서 ID 를 재발급 받을 수 없다는거에요. 그래서 이건 해당 프로듀서 어플리케이션이 살아있는 세션 내에서만 메시지 발행이 중복이 되지 않습니다. 만약 멱등성 프로듀서 어플리케이션이 메시지를 보내다가 죽은 경우, 다시 재부팅되서 메시지를 보내는 경우에는 두 개의 메시지가 전송되는 케이스는 존재하는거죠. 그래서 엄격하게 메시지 발행을 하나로만 보장하려면 카프카 트랜잭션을 사용해야하는거죠. 물론 현재 저희 어플리케이션에서는 Payment Service 가 트랜잭셔널 아웃박스 패턴으로 메시지를 하나만 발행하고 있기 때문에 메시지는 여러건 발행되지 않으므로 의미는 없긴합니다. 그리고 여담이긴 하지만 저 같은 경우는 일관성이 엄격하게 중요한 어플리케이션에서 하나만 믿고 로직을 작성하기 보다는 불확실한 것들이 있는 경우에는 여러가지 케이스를 고려해서 2차까지 방어 로직을 작성하는 것을 선호합니다. 도움이 되셨으면 좋겠네요. 감사합니다.

완강!!!!!!!!!!!!!!

축하드립니다~~ 주말에도 열심히 하시는 것 같던데 항상 좋은 결과 있길 바랄게요. 질문도 필요하시면 언제든지 주세요~

테스트 시 오류

안녕하세요~ 질문 남겨주셔서 감사합니다. 똑같이 따라 한 것 같은데 무결성 제약 조건이 나서 불편하셨겠네요..에러 메시지를 보니까 외래 키 제약 조건 위반을 나타내는 것 같네요. 이 경우, ledger_entries 테이블에 데이터를 삽입하려고 할 때 transaction_id 열의 값이 ledger_transaction 테이블의 id 열에 존재하지 않는 값이기 때문에 발생한 것으로 보입니다. ledger_entries 테이블에 삽입하려고 하는 transaction_id 값이 ledger_transaction 테이블의 id 열에 존재하지 않기 때문에 이 에러가 발생한 것으로 보이는데요. 비즈니스 로직이나 테스트 코드 로직을 다시 검토해보시는걸 추천드립니다~ 제 프로젝트에서는 잘되는데 왜 안되는지 모르겠군요..