[과제 회고] K사 서버 개발하기

Redis-Kafka 기반의 개념을 학습한 이후 실전과제를 진행하게 되었다.

이번 과제는 큰 제약사항이 없이 중점을 두어야 하는 포인트가 전적으로 나에게 있었던 점을 활용해서 그 범위와 선을 정하는 것이

 

📄 과제 소개

다수 서버 환경에서도 안정적으로 동작하는 커피숍 주문 시스템을 구현하기

1. 커피 주문에 필요한 메뉴를 구성하고 조회가 가능해야 합니다.
2. 커피 주문은 포인트로 가능합니다.
3. 커피 주문내역을 통해 인기 있는 메뉴를 추천합니다.

🔥 구현 필요 API 

1. 커피 메뉴 목록 조회 API
2. 포인트 충전하기 API
3. 커피 주문, 결제하기 API
4. 인기 메뉴 목록 조회 API

실습 과제를 통해 경험했던 부분과 설계 의도를 정리하고자 한다.

 

🧩 설계 요약

• 멱등성 키 기반 중복 요청 방지
• DB + 서비스 레벨 이중 방어로 동시성 대응
• 주문 결제와 집계 로직의 명확한 책임 분리
• 이벤트 기반 비동기 처리로 확장성 확보
• 실시간 조회에 적합한 Redis 집계 구조 적용

---

 

🤔 설계 및 구현 간 고민했던 부분

트랜잭션의 범위가 적합한가?

일반적으로 사용했던 범위는 비즈니스 로직의 실패가 발생했을 때 롤백이 필요한 경우 트랜잭션을 설정하여 데이터의 오염을 최소화하는 것이 목적이었다.

 

이번에는 집계 기능도 추가 구현하게 되면서 집계를 실패했을 경우에도 트랜잭션이 실패되어야 하는가에 대한 고민을 하게 되었다.

 

그래서 다음과 설계하고자 했다.

 

핵심 트랜잭션만 최소 단위로 유지하자!

주문 도메인

• 주문 생성
• 주문 상태 변경
  👉 주문 자체의 정합성만 보장

포인트 도메인

• 포인트 차감
• 포인트 거래 이력 저장
  👉 금전 처리의 원자성만 보장

집계 / 전송

• Kafka 이벤트 발행
• Redis 집계
  👉 트랜잭션 밖에서 비동기 처리

그 의도가 드러난 코드는 아래와 같이 작성했다.

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handle(OrderCompletedDomainEvent event) {
    // Kafka 이벤트 전송
}

이 방식의 의미

• 주문 트랜잭션이 정상 커밋된 이후에만 이벤트를 전송
• Kafka 전송 실패가 되더라도 주문/결제는 롤백되지 않음
• 외부 시스템 장애가 핵심 비즈니스 로직에 전달되지 않음

이를 통해 주문/결제는 안정적으로 유지되고 집계 및 데이터 수집 로직은 독립적으로 확장 가능하게끔 구조를 만들었다.