kafka 강의 부터는 아직 최신 버전으로 영상이 업데이트 되지 않은거 같은데 혹시 올해 업데이트 될 예정일까요??업데이트가 된다면 이 후에 강의를 듣고 싶어서요!!

concurrency 관련하여 궁금한점이 있습니다. 하나의 topic (ex. email.send) 에 5개의 파티션이 있다고 가정. 같은 groupId 로 지정된 consumer 2 (A, B)개가 있고 각각 concurrency=3 으로 설정이 되어 있다고 가정 이런 경우, 같은 groupId 내의 컨슈머는 같은 partition 을 consume 할 수 없으니 1개의 thread 는 동작하지 않게 된다고 보면 될까요?A-1 thread ===> partition 1 A-2 thread ===> partition 2 A-3 thread ===> partition 3 B-1 thread ===> partition 4 B-2 thread ===> partition 5 B-3 thread (동작안함) ====> x추가로 실무에서는 일반적으로 concurrency 옵션을 사용하는지 궁금합니다.

하나의 consumer 에서 concurrency 옵션을 통해 멀티 쓰레드로 동작이 되는지 테스트를 해봤는데 강좌화면에서처럼 consumer 가 멀티스레드로 동작하지 않는것 같습니다. partition : 3개concurrency : 3partitional.class: org.apache.kafka.clients.producer.RoundRobinPartitional 로그 : 로그를 봐서는 roundrobin 으로 설정을 했음에도 하나의 partition 으로 메시지가 들어가는것 같습니다. 그리고, consumer 도 하나의 스레드로 message 를 consume 하는것으로 보입니다.2025-10-15T16:01:15.466+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-4","price":4000} 2025-10-15T16:01:17.473+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:17.474+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-8","price":8000} 2025-10-15T16:01:19.480+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:19.481+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-16","price":16000} 2025-10-15T16:01:21.485+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:21.486+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-15","price":15000} 2025-10-15T16:01:23.491+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:23.491+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-5","price":5000} 2025-10-15T16:01:25.494+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:25.495+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-18","price":18000} 2025-10-15T16:01:27.499+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:27.501+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-3","price":3000} 2025-10-15T16:01:29.510+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:29.510+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-9","price":9000} 2025-10-15T16:01:31.514+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:31.515+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-13","price":13000} 2025-10-15T16:01:33.522+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:33.522+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-1","price":1000} 2025-10-15T16:01:35.527+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:35.529+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-11","price":11000} 2025-10-15T16:01:37.532+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:37.532+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-19","price":19000} 2025-10-15T16:01:39.538+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:39.538+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-7","price":7000} 2025-10-15T16:01:41.539+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:41.539+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-6","price":6000} 2025-10-15T16:01:43.543+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:43.544+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-20","price":20000} 2025-10-15T16:01:45.554+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:45.555+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-10","price":10000} 2025-10-15T16:01:47.560+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:47.560+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-14","price":14000} 2025-10-15T16:01:49.566+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:49.566+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-17","price":17000} 2025-10-15T16:01:51.568+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:51.568+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-2","price":2000} 2025-10-15T16:01:53.575+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:53.577+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-12","price":12000} 2025-10-15T16:01:55.581+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. github 소스코드 : https://github.com/writer0713/kafka-practice/blob/4cee9e560b2459c4bcbb6b183f3791d70cddd3d1/src/main/kotlin/com/writer0713/kafkapractice/service/OrderService.kt#L34

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요, 선생님! 강의 알차게 잘 수강하고 있습니다.현재 90% 수강 완료하였는데, 어렵고 힘들게 여기까지 온 만큼 저의 역량도 비교할 수 없을 정도로 많이 성장한 것 같습니다.먼저 감사의 말씀을 드립니다.일단 현재 게시글 목록 최적화 전략 구현(64강) 강의를 수강 중인데, 이전의 강의 내용(게시글 조회 최적화 전략)과 비교하였을때 최적화 전략을 수립하는 과정과 관련하여 몇가지 의문점이 들어 질문드리게 되었습니다.의문점) - 게시글/카테고리에 대한 게시글 목록 모두 전략을 나누어야 하는가?의문점이 들었던 과정) - 일단 크게 보았을때, 게시글 내용에 대한 캐싱(articleId)과 게시글 목록(*특정 카테고리, board로 지칭)에 대한 캐싱(boardId)으로 내용을 나눌 수 있을 것 같습니다.- 여기서 드는 제 개인적인 생각은, (일단 전략의 당위성이나 세부적인 내용 상관없이) 캐싱전략을 너무 세세하게, 오히려 성능적 이점보다는 관리적 비용이 더 크게 소모되지 않을까 하는 염려가 들 정도로 배꼽이 더 큰 전략/관리방안을 각각 구분해놓는 것이 아닌가하는 생각이 들었습니다.- 예를 들어, 게시글 목록 최적화 전략의 경우 말씀하신대로 최초 목록 조회 진입 시 보여지는 내용이기도 하고 이는 모든 사용자에게 공통적으로 적용할 수 있는 정책이므로 관리의 당위성이나 책임이 명확하다고 생각하였습니다.- 하지만 게시글 조회 최적화 전략의 경우, 목록 최적화 전략을 수강한 이후에는 "게시글 조회"역시 어떻게 보면 그 게시글을 보고싶은 사용자 일부에 대해서만 보여지는 글이므로..지금처럼 모든 생성 글/댓글/좋아요에 대해 ArticleQueryModel 데이터를 생성하는 것이 비용효율이나 관리효율면에서 과연 올바른 방향인지 다소 의문이 들게 되었습니다. 또한, 이러한 전략수립의 당위성을 떠나서 각 조회기능별로 전략을 구상하는게(단건/목록 등) 수립은 가능하더라도 관리가 힘들 것 같은데, 실무적으로 관리가 가능할지 의문이 들기도 하였습니다.최종 질문)- 제가 올바르게 강의내용을 이해하지 못하여 질문드리는 것 일 수 있기에, 일단 제가 들었던 의문이 선생님께서 생각하셨을때, 타당한 의문일지 궁금합니다.- 타당하다면 아래와 같은 "게시글 단건" 조회 전략을 생각할 수 있을 것 같은데, 혹시 바람직한 전략이 될 수 있을지 고견을 요청드려보고자 합니다.- 또한 실무적으로 이러한 다양한 관리전략을 수립하게된 계기가 "성능문제" "사용자 패턴에 따른 문제점 예상" 등, 여러 문제 중 어떠한 부분이 가장 중요하게 작용하는지 궁금하여 질문드립니다.[단건 조회전략 구상 방안] 게시글 조회 전략을 만약 구상한다면(세부적인 전략구현은 생략)- 지금처럼 단건 데이터 생성마다 articleQueryModel을 구성하는 것이 아니라, 각 카테고리별 보여지는 1000개의 데이터에 대해 articleQueryModel 데이터를 구성한다. (*게시글을 보는 것도 결국 최신 1000개의 데이터에 대해서만 볼 것이기 때문이다.)- 인기글 데이터 생성 후 해당 인기글에 대한 articleQueryModel 데이터를 구성한다.(*인기글 데이터에 대해서만 단건 조회 트래픽이 몰릴 것으로 예상할 수 있기 때문이다.)읽어주셔서 감사드립니다.

만약 카프카를 사용하고 있고 처리 실패하는 경우 retry 큐로 보내서 재시도 하는 방식을 사용하고 있다고 가정하겠습니다. 만약 서버가 메시지를 받아서 처리하던 중에 리밸런싱이 발생했습니다. 메시지를 성공적으로 처리했고 커밋을 하려했지만 리밸런싱이 발생해 커밋을 하지 못했습니다. 그럼 그 메시지는 다른 컨슈머가 다시 받아서 중복으로 처리할 수 있을것 같은데 어떻게 방지를 할 수 있나요..? 찾아보니 인박스 패턴이라는것이 있던데 메시지를 받았을 때 상태를 저장하고 이후에 재시도를 해도 상태값이 있다면 패스하는 방식으로 이해를 했습니다. 하지만 위에 상황에서 첫 컨슘에서 메시지를 처리하고 있다가 리밸런싱이 발생했고 이후에 다시 처리할 때 상태값이 있어서 패스 했습니다. 하지만 이후에 첫 컨슘에서 처리중에 예외가 발생했다면 어떻게 처리를 해야할까요...?

안녕하세요! 강의 너무 잘 보고 있습니다!강의를 보는 중 궁금한 부분이 생겨 질문드려봅니다!@GetMapping("/callback") fun callback( ... return ResponseEntity.status(HttpStatus.FOUND) .location(URI.create("https://localhost:3000")).build()콜백 함수에 return을 이렇게 작성하셨는데요!만약에 서블릿객체를 이용해서 쿠키를 담지 않고 아래와 같이 하는 방법은 어떻게 보시는지요...?? 같은 동작을 할 것으로 예상은되는데 보편적인 스타일이 궁금합니다 ㅋ.ㅋ;```return ResponseEntity .status(HttpStatus.FOUND) .header("Set-Cookie", "authToken=$token; HttpOnly; Path=/; Max-Age=${60 60 24 * 7}") .location(URI.create("http://localhost:3000")) .build()```

안녕하세요!다른 분 질문에 대한 답변을 보고 기본적인 의구심은 해소되었는데요. 혹시 몰라 확인차 여쭙습니다.09:38 피피티에서요.나머지 연산을 이용해서 물리샤드, 논리샤드를 구분하셨잖아요.제가 이해하기로 나머지가 0이면 1번 샤드, 1이면 2번 샤드...이렇게 의도하시려고 했던 것 같아요.https://inf.run/7i72V여기에서 답변해주신 것과 피피티의 샤드 번호 현황?이 달라서 조금 혼란스러웠습니다. 링크 답변을 보면 아주 간단한 샤딩 예시였지만, 물리 샤드가 두 개일 때 % 2를 적용하면 1번 샤드(나머지 연산결과 +1)에는 article_Id가 [2, 4, 6, 8]이 들어가고 2번 샤드에는 [1, 3, 5, 7]이 들어갈 테죠.논리 샤드 기준으로는1번 논리샤드 = [4, 8]2번 논리샤드 = [1, 5]3번 논리샤드 = [2, 6]4번 논리샤드= [3, 7] 1번 물리 샤드에는 1, 3번 논리 샤드2번 물리 샤드에는 2, 4번 논리 샤드(링크 답변과 동일한 분포)이게 제가 위의 답변을 강의 자료에 적용해서 이해한 샤딩 현황입니다! 실제 프로덕션에서도 이렇게 샤딩하는지는 모르겠지만 교육 목적 상 간단한 해싱이었어도 제대로 이해하고 넘어가고 싶었습니다.PPT만 보고는 나머지 연산이 어떻게 사용된 건지 이해가 안 됐는데 답변 보고 이해가 돼서 확인 차 질문드렸습니다.추가적으로 클라이언트는 논리 샤드만 알고 있다고 하셨는데 그럼 물리 샤드 번호는 물리적으로 나뉜 샤드를 구분하는 데만 사용하고 비즈니스 로직에서는 사용되는 일이 없을까요?감사합니다.

쿠폰에 관련되어서 좀 더 참고할만한 자료가 있을까요?

메시지 키가 있을 경우 전달되는 파티션이 변경되는 것을 방지하기 위해 충분히 큰 파티션으로 생성을 해야한다. 해당 부분에 대해 궁금한 점이 생겨 질문올립니다. 여기서의 충분히 큰 파티션은 어떻게 산정을 하면 좋을까요? Spring Application으로 Consumer를 구현한다고 했을 때, 충분히 큰 파티션 생성 시 Consumer : Kafka Topic = 1 : N구조로 구독을 하는 방향으로 만들면 되는 건 지 궁금합니다. 

게시글 조회 기능을 확장하려고 할 때 댓글을 조회하는 방향에 대해 고민이 있어서 질문 남깁니다.게시글 하나를 보는 페이지로 사용자가 이동해서, 게시글의 내용과 댓글들까지 이동한 페이지에서 그려야 할 때 게시글 정보와 해당 게시글의 모든 댓글을 가져오는 기능을 신규로 추가하려고 합니다. 해당 기능의 구현에 대해 2 가지 방향을 고민해봤습니다.게시글처럼 댓글까지 캐싱하는 방법Hot data 로 캐싱된 게시글들의 댓글들을 캐싱하는 것을 고민했을 때, 댓글은 게시글보다 훨씬 많은 양이기 때문에 캐싱에 대한 비용이 너무 커지는 것에 부담이 생기는 문제가 있다고 생각합니다.댓글에 대한 조회는 매번 댓글 서비스에서 조회하는 방법실시간으로 게시물의 댓글을 계속 조회한다면, 조회 서비스에 읽기 부하가 크게 걸릴 것으로 생각합니다. 두 방식 다 장단점이 있다고 생각하는데, 강사님께선 어떤 방식으로 게시글 + 댓글 조회 기능을 구현하실지 의견이 궁금합니다!

해당 강의를 수강하기 전에 사전 학습으로 준비하면 좋은 내용들(MySQL, Redis, Kafka, 시스템 설계 등)에 대해 추천해주실 만한 책이나 강의가 있을까요?저에게는 이 강의가 다소 어렵게 느껴져서, 관련 내용을 따로 공부한 후 다시 수강하고 싶습니다.혹시 강의 내용과 연관되어 쿠케님께서 좋다고 느끼셨던 자료나 도움이 되었던 책, 강의 등이 있다면 공유 부탁드립니다!

이전 강의를 듣지않고 수강하고 있습니다.이전 강의에 대한 정보가 없어서 간혹 영상에 보이는대로 따라서 메우고 있는데, response 함수에 대한 정보는 아직 화면에 나온 적이 없는거 같아서요. 어차피 JSON으로 응답이 오는거 같아서 c.JSON 을 통해 처리했습니다.아직 완강하기 전이라 후반부에 나오는지는 잘 모르겠지만 뼈대가 되는 코드에 대한 정보가 조금 더 있었으면 좋겠습니다. 강의 잘 듣고 있습니다. 감사합니다.

github에는 actions탭에 정상적으로 워크플로우가 런 됩니다. 하지만 code-deploy 탭으로 이동해 확인하면 배포상태가 번번히 실패로 뜹니다. 강의안대로 잘 따라갔습니다. 원인을 찾아보려했지만 찾아지지 않아 글 남깁니다. 감사합니다.

안녕하세요, 강의를 통해 대규모 시스템 설계에 대한 다양하고 실무적인 방법을 배우게 되어 감사히 수강하고 있습니다!수강중 Transactional Outbox 테이블 관련하여 궁금한 부분이 있어 질문드립니다.실무에서는 보통 "Outbox 테이블에 Insert -> kafka send 후 Outbox 상태 Update" 하는 방식으로 쓰일까요? 강의에서는 간단히 Delete로 구현한다고 말씀주셔서 질문드려봅니다!Update 하는 방식도 자주 쓰인다면 Outbox 테이블은 파티셔닝(p20251001 와 같이)하여 관리하고 주기적으로 삭제하는 방식일지도 궁금하여 질문드립니다!  

안녕하세요 강사님!카프카를 사용하면서 궁금한 점이 있어서요~ 예를 들어 주문 시스템을 구현한다고 하면요.주문에 대해 상태가 계속 바뀌어 해당 이벤트를 받을 수 있도록 카프카를 붙이려고해요.consumer가 동일한 주문 id에 대해 상태 업데이트를 해야 하니, producer가 순서 보장되도록 카프카 key도 동일하게 셋팅하면 consumer는 순서대로 status를 제대로 update 하는데요. 만약 producer가 메시지 발행을 비동기적으로 진행하도록 구현했다고 하면,무언가 이슈로 주문 생성 -> 주문 취소 순이 아닌 주문 취소 -> 주문 생성 순으로 발행되었다면consumer 입장에서 메시지 순서가 제대로 들어왔음을 어떻게 인지할 수 있을까요..? 이런 상황은 발생하지 않을까요..? ㅎㅎ

최근 카프카 버전에저는 zookeeper 가 아닌 KRaft 를 사용하는 것으로 바뀌는 등 몇가지 차이점이 있는데 강의 내용으로 학습한 후 변화된 버전에 맞춰서 변경할 때 러닝커브가 어느 정도가 될지 궁금합니다

강사님 안녕하세요, 강의 잘 듣고 있습니다.카프카의 성능과 안정성을 확보하기 위한 다양한 기법과 설정에 대해서 강의에서는 해당 부분이 깊이 다루어지지 않아, 이후에는 수강생이 스스로 학습해야 한다고 하셨는데요.현재 현업에서는 카프카를 직접 사용하지 않고 있어 개인적으로 학습이 필요한 상황입니다.추천하실 만한 도서나 강의, 혹은 효과적인 학습 방법이 있을지 궁금합니다.

쿠케님 안녕하세요!우선 좋은 강의 제작해주셔서 정말 감사합니다. 강의 들으면서 대규모 시스템을 설계할 때는 어느 것을 신경써야 하고, 또 주의해야 하는지 많은 인사이트를 얻고 있어요. 추석 연휴 동안 제 나름대로 열심히 들어서 이제 한 개 섹션만 남았는데, 완강을 한 뒤에 강의에서 얻은 것들을 토대로 대규모 트래픽을 가정한 서비스를 설계하고, 개발해보려고 합니다. 강의로만 듣고 넘기기에는 아까운 내용들이 많아서 확실하게 제 것으로 만들어야겠다 싶더라고요. 일하면서 써먹으면 더없이 좋겠지만 아쉽게도 그럴 환경은 안 되어서요.. ㅎㅎ 그래서 나름대로 구상을 해보면서 강의를 듣고 있는데, 문득 강의에서 다룬 아키텍처와 기술을 한 번에 다 도입하는 건 오히려 학습 효율을 떨어뜨리는 선택이 아닐까 싶은 생각이 들어서요. 실무에서 Redis 정도는 사용해봤지만, 분산 데이터베이스나 MSA도, Kafka나 CQRS도 이 강의에서 처음 사용해봤습니다. 개념은 대충 주워 듣긴 했지만, 제대로 공부해본 적도 없고요. 결론적으로 하나씩 해보는 게 낫겠다 싶은데, 강의에서 다룬 내용 중 어느 것을 먼저 학습하는 게 좋을지 쿠케님께 조언을 구하고 싶어요. 물론 정답이 없는 문제지만, 지금 당장 제가 일하는 환경에서는 써먹을 일이 별로 없는 내용들이다 보니 무엇을 먼저 하는 게 좋을지 선택하기가 어렵네요. 감사합니다.

안녕하세요, 강사님!Kafka 관련 강의를 듣다가 기술 선택의 기준에 대해 궁금한 점이 생겨 질문드립니다. 현재 강의에서 Kafka를 이벤트 브로커(Event Broker)로 사용하고 계신데,Redis의 Pub/Sub 또는 Redis Streams 기능을 이용하면비슷한 형태로 서비스 간 메시지 전달을 구현할 수도 있을 것 같다는 생각이 들었습니다. 그래서 아래 두 가지 부분이 궁금합니다  Kafka를 선택하신 이유 또는 기준이 무엇인지 예: 처리량, 확장성, 영속성, 장애 복구 등 기술적 관점에서 어떤 요소가 결정적이었는지혹은 실제 서비스 환경에서 Redis 기반 메시징을 사용했을 때의 한계가 있었는지도 궁금합니다. 이벤트 브로커(Event Broker)와 메시지 브로커(Message Broker)의 개념적 차이 두 용어가 거의 비슷하게 사용되는 경우도 많은데,Kafka가 ‘이벤트 브로커’로 분류되는 이유가 무엇인지 알고 싶습니다.실제로 시스템 설계 시, 어떤 기준으로 두 개념을 구분하고 선택하시는지도 궁금합니다. 제가 이해하기로는 Redis는 단순한 메시지 전달 중심,Kafka는 이벤트 스트리밍 및 데이터 파이프라인 중심으로 알고 있는데,이 부분이 맞는 방향인지도 확인해보고 싶습니다. 

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.강사님, 최적화를 진행할 때 보통 어떤 순서로 고민하시나요?예를 들어 트래픽이 몰릴 때 먼저 어디를 확인하고, 어떤 기준으로 개선 방향을 정하시는지가 궁금합니다.