안녕하세요 강사님. 강의 잘 듣고 있습니다. 이번 시간에 강사님께서 Spring WebFlux와 Spring Web MVC를 혼용해서 사용하는 경우, 결국에는 Web MVC의 기본 스레드인 톰캣 스레드를 사용해서 스레드 고갈이 될 수 있다고 하셨습니다. 따라서 내부적으로는 WebFlux의 이벤트 루프 스레드가 아닌 톰캣 스레드를 사용해서 블로킹되는 현상이 발생한다로 해석하면 될까요? 저는 혼용할 경우, Mono/Flux 타입 응답에 한해서는 동시 요청 발생 시 이벤트 루프 스레드를 사용하여 IO 작업을 대기하지 않고 해당 스레드가 다른 일을 처리하러 가는 것으로 알고 있었습니다. 혹시 이러한 상황에서 어떤 스레드를 사용하는지 테스트 해볼만한 좋은 방식이 있을까요? 감사합니다.
안녕하세요. 강사님 강의 잘 들었습니다. 한가지 질문이 있습니다. 주문 생성과 주문 처리api를 나누고 사용자가 결제가 되면 주문 처리 api를 호출하는걸로 알고있습니다. Orchestaration 방식으로 처리할 때 OrderConfirmEvent를 발행하면 제 서비스로 예를 들면 재고, 쿠폰, 적립금 서비스에서 consume하여 처리를 하고 있습니다. 그런데 주문 처리 api에서 재고는 처리되었지만 쿠폰은 실패할 경우 어떻게 보상 트랜잭션을 주어야할지 모르겠습니다. 결제가 된 주문이라 바로 보상을 하는것 보다는 dlt topic에 넣고 재처리를 하고 만약 재시도 3번을 하고 나서 실패할 경우 환불을 해줘야할까요? 주문 처리 api에서는 어디가 실패한지 모르니까요 혹시 어떤식으로 해야할지 조언좀 받을수 있을까요?
안녕하세요. 강의 잘 들었습니다. 분산 시스템이 맞는지는 모르겠지만,, 다른 회사의 API들을 여러개 사용할때에 궁금증이 있어서 질문 드립니다. 문제 상황은 아래와 같습니다. 우리 쪽에서는 이미 사용자가 토큰 기반으로 인증된 상태 이며, 이 사용자의 요청을 대신해 외부(회사1, 회사2)의 API를 호출 해야 하는 상황입니다. 또한, 사용자가 버튼을 눌렀을 때 새 브라우저 창을 띄워 회사2의 웹 애플리케이션으로 이동 해야 하는데, 이때 로그인 과정을 생략하고 자동으로 접속(SSO) 되도록 만들고 싶습니다. 질문 1⃣ API 인증 전파 관련 우리 서버가 회사1·2 서버로 요청을 보낼 때, 상대 서버에서는 “이 요청이 실제 인증된 사용자로부터 온 것”임을 어떻게 검증하는 게 일반적인가요? 2⃣ 브라우저 SSO 관련 새 탭을 열어 회사2 웹 서비스로 이동 시, 재로그인 없이 자동으로 인증(Single Sign-On) 되게 하려면 어떤 방식이 많이 사용되나요?
안녕하세요. 주문 처리에 관련해서 질문 있습니다!! 고민하다가 질문드려요 ㅠ! 중복 주문을 해결하기 위해 주문 생성 API , 주문 처리 API를 나누는걸로 이해하고 있습니다. 만약 쇼핑몰에서 사용자가 주문을 할때 주문 생성 API를 요청하고 결제처리 (PG사) 성공하면 주문 처리 API(재고차감 등등) 를 하는걸로 알고 있습니다. 하지만 주문 생성 API에서 수량을 검증한다고 하더라도 결제를 완료하고 주문 처리를 할때 다른 사용자에 의해서 재고가 부족할수 있는 상황이 있다고 생각합니다. 이럴때는 실무에서 어떻게 해결하는지가 궁금합니다!!!! 비동기적으로 보상해준다고 하면 뭔가 사용자입장에서 결제까지 했는데 재고가 부족해서 주문처리가 실패하여 환불까지된다?.... 이게 좀 비효율적이라 생각해서요!! 답변 부탁드립니당 실무에서는 어떻게 사용하나요 ! 궁금해요 ㅠㅁㅠ
안녕하세요 준형님! 우선, 강의 정말 잘 들었습니다. 정말 정말 많이 배웠습니다 🙇🏻🙇🏻🙇🏻 다름이 아니라, 데이터 버저닝 파트에서 컨슈머의 멱등성을 보장하기 위해 주문 서비스가 재고 차감 이벤트에 version을 담고, 상품 서비스에서는 JPA가 관리하는 상품 version과 이를 동등성 비교하여 중복 소비를 방지하는 방식에 대해 질문드리고 싶습니다. 이 접근 방식에서 많은 인사이트를 얻었지만, 상품의 version을 주문 서비스가 반드시 알아야 한다는 점은 조금 와닿지 않았습니다. 테스트에서는 version = 0부터 시작하니 문제가 없어 보였으나, 여러 이유로 두 version 값이 어긋나면 오히려 소비해야 할 이벤트까지 멱등 처리되어 버릴 수 있다고 생각했습니다. 그렇다고 이를 해결하기 위해 주문 서비스가 상품 서비스로부터 version 이벤트를 직접 받아 관리하는 것도 과한 방식처럼 느껴지는데요, 이 부분에 대해 준형님의 의견을 들을 수 있다면 좋을 것 같습니다. 시간 편하실 때 부담없이 답변 주시면 감사하겠습니다 🙂
안녕하세요. 먼저 좋은 강의 감사드립니다. 데이터 버저닝에서 이해가 가지 않는 부분이 있어서 질문 드립니다. 낙관적 락을 사용하는걸 봤습니다. 결과적으로 발행시와 소비시의 버전이 같아야 하는데, 대규모 시스템에서 장애가 발생하지 않으려면 프로듀서에 아이디 1인 상품 발행하고 나서 컨슈머에서 처리하기 전까지 절대 새로운 이벤트를 발행하면 안되는거 아닌가요? 만약 컨슈머에서 처리하기 전에 이벤트를 발행하면 똑같은 버전이 후에 계속 들어와서 이 재고 업데이트는 무시되는게 아닌가 해서 질문드립니다. 맞다면 재고 감소 멱등성은 어떻게 해결하면 좋을지 고견 듣고 싶습니다. 감사합니다.
안녕하세요. 준형님. 강의와는 조금 벗어나는 얘기라서 답변을 해주시지 않아도 괜찮습니다.! 복제를 구성하는 경우 복제 지연에 대해서 고민을 하게 되었는데, 마땅한 대안을 내지 못해서 이렇게 질문드리게 되었습니다. 혹시 실무에서나 일반적으로 복제 지연을 대응(해결)하기 위한 해결책에는 어떤것이 있을까요...???
