이커머스 서비스에서 발생할 수 있는 동시성 문제들을 정리하고, 다양한 방법으로 동시성 문제를 해결해 보며 겪은 경험들을 공유해 보자 합니다. 동시성 문제가 발생할 수 있는 유즈케이스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; ..

AWS EKS Cluster를 생성 후 node를 확인하기 위해 node를 확인하는 명령어(kubectl get nodes)를 입력했는데 아래 에러가 발생했다. 대충 에러 로그가 의미하는 바는 현재 권한이 없는 게 문제인 것 같은데, eks 사용하기 위해 별도의 IAM을 만들어 eks 관련 역할을 부여해 주었는데도 위와 같은 에러가 발생해 꽤나 삽질을 하느라 시간을 소비했다. 에러를 해결하기 위해 시도했던 과정들을 나열을 해보자. 1. 로컬의 kubectl 설정 업데이트aws eks update-kubeconfig --region --name   위 명령어로 현재 로컬의 kubectl 설정(kubeconfig 파일)을 업데이트하여 EKS cluster에 접근이 가능하도록 했다.Updated contex..

이번 글에서는 최근 진행한 프로젝트에서 도메인 타입에 따라 데이터를 조회하는 서비스 로직을 전면적으로 리팩터링한 경험을 공유합니다. 특히 도메인이 늘어날수록 반복적으로 등장하는 if문과 switch-case문으로 인해 발생한 문제점을 어떻게 해결했는지 예시와 함께 살펴보겠습니다. 배경 및 문제점기존 금융 데이터 처리 시스템은 도메인(일반, 은행, 카드, 증권 등)별로 서로 다른 데이터 조회 및 변환 로직을 갖고 있었습니다.각 도메인마다 데이터 변환 로직을 개별적으로 구현이 되어 있는데, 이로 인해 시간이 지날수록 다음과 같은 문제들이 발생했습니다. 기존 코드에서는 여러 도메인 타입(general, bank, card, insurance 등등)의 데이터를 조회하기 위해 서비스 레이어마다 유사한 switch..