TL;DRKafka Streams 애플리케이션에서 5초마다 들어오는 주가 데이터(KStream)와 오전에 한번 업데이트되는 valuation 데이터(KTable)를 조인하여 조건에 맞는 시그널 기업 메시지를 생성하려 했지만, 파티션 불일치(코파티셔닝 미흡)로 인해 동일 기업의 시그널이 여러 Task의 로컬 상태 저장소에 분산되어 중복 생성되는 문제가 발생했습니다. GlobalKTable을 사용해 보았으나, 비동기 업데이트로 인한 약간의 지연 때문에 중복 필터링에 실패했습니다. 결국, 동일 키가 반드시 동일 파티션에 위치하도록 파티션 수를 맞추거나 재파티셔닝을 수행하는 코파티셔닝 방식을 적용해야 중복 메시지 문제를 확실히 해결할 수 있다는것을 배웠습니다. Kafka Streams를 활용하여 실시간 피드 제..

TL;DR주식 시장 마감 후 코스피/코스닥 종목의 종가와 수익률을 계산해 시황 피드를 생성하는 시스템에서 종가 변동률 계산 오류가 발생했습니다. 문제는 시황 정보 생성 시점에 당일 종가 정보가 DB에 아직 저장되지 않아 이전 영업일 데이터를 참조한 데 있었습니다. 이를 해결하기 위해 피드 생성 서버 코드를 수정하여 시황 정보 수신 시 종가 데이터 유무를 확인하고, 종가 정보가 없으면 상태를 저장한 후 스케줄러를 통해 주기적으로 재시도하는 방안을 도입했습니다. 이로써 데이터 정합성을 확보하고 버그를 수정했습니다. 항상 버그는 퇴근하고 발생하는 것 같은 기분이 듭니다.  주식 시장이 마감되고 코스피/코스닥에 상장된 종목들의 종가 및 종목 수익률을 계산하여 당일 시황의 전반적인 상황을 피드로 생성하여 제공하는..

문제기존 Protobuf 포맷으로 정의된 스키마(Version 1)에 새로운 inner message를 생성하여 스키마 버전(Version 2) 업을 하는 경우 이전 버전 스키마가 새로 생성한 inner message 를 참조하지 못하여 스키마 업그레이드를 하지 못하는 문제가 발생. 해결스키마에 inner message를 생성하는 방식이 아닌 별도의 schema를 생성하여 수정할 스키마에서 이를 참조하는 방식으로 해결 + Terraform Provider로 Confluent Schema Reference 적용 시 발생한 문제A스키마에서 B스키마를 참조할 경우 참조할 스키마(B)가 먼저 생성이 되어 있어야 한다. "A" 스키마에서 새로운 메시지인 "B" 스키마를 참조하려고 할 때, "B" 스키마 생성과, ..

이커머스 서비스에서 발생할 수 있는 동시성 문제들을 정리하고, 다양한 방법으로 동시성 문제를 해결해 보며 겪은 경험들을 공유해 보자 합니다. 동시성 문제가 발생할 수 있는 유즈케이스Case 1 (조회한 상품 재고 수량이 맞지 않는 경우)1. 사용자 A가 재고가 5개인 상품을 조회하고 재고 1개 차감 요청, 트랜잭션 시작2. 사용자 B가 동시에 동일 상품의 상품을 조회, A의 트랜잭션이 아직 커밋되지 않았기 때문에 재고가 5개인 것으로 확인3. 사용자 A의 트랜잭션이 커밋되어 실제 재고는 4개로 업데이트4. 실제 상품의 재고는 4개이지만 사용자 B가 조회한 상품의 재고는 5개로 재고 정합성 불일치 문제 발생 Case 2 (동시에 상품을 주문할 때, 상품의 재고가 부족한 경우)1. 사용자 A가 재고 3개 차..

주문 결제를 이벤트 기반 아키텍처로 구축하기이 글에서는 주문 결제 시스템을 이벤트 기반 아키텍처로 전환하면서 겪었던 문제와 그 과정을 공유하고자 합니다.  현재 이커머스 프로젝트의 주문 결제 시스템은 한 트랜잭션 내에서 동기 처리 방식으로 처리하고 있습니다.  현재 OrderUseCase를 간단히 살펴보면사용자 조회 -> 상품 조회 -> 상품 재고 조회 -> 주문 -> 결제 -> 재고 차감 순으로 주문 결제 시스템이 이루어져 있습니다. 그럼 이 주문 결제 시스템을 이벤트 기반 아키텍처로 구축하면서 겪었던 문제와 과정을 정리해 보겠습니다. 이벤트 기반 아키텍처로 변경하는 이유결합도 감소현재 주문 결제 시스템은 상품 재고 관련 로직, 결제 로직이 주문 로직에 깊게 관여되어 도메인끼리 강한 결합을 갖고 있다는..

Facade Pattern을 사용하여 시스템 응집도와 재사용성을 어떻게 개선할 수 있을까? 이전 글에서 OrderService에서 의존하고 있는 컴포넌트가 너무 많아 응집도가 떨어지고 강결합이 발생하는 문제가 있었다고 언급을 했었습니다.그래서 이번엔 facade pattern을 E-commerce 서비스에 적용하여 리팩터링 한 내용을 정리해보려고 합니다. 기존 OrderService 코드public class OrderService { private final UserReader userReader; private final UserPointManager userPointManager; private final UserPointValidator userPointValidator; ..