[부록] Consumer Retry vs Command Replay 처리

1. Consumer Retry vs Command Replay 처리 

    : 만약 결제는 성공했는데, 배송 생성이 실패했다면? 환불하는게 적합한 의사결정일까?

      배송생성을 재시도 하는게 적합한 의사결정일까?

     그럼 환불하면 안 된다면, 시스템은 어떻게 복구되어야 할까?

 

 

2. 비동기 이벤트 기반처리 시 실패유형정리

순번	실패 유형	예시	처리방안
1	이벤트 전송실패	Kafka publish 실패	Transactional Outbox Pattern
2	Consumer 처리실패	DB timeout or 외부 api 장애 등으로 일시적 장애의 경우	Kafka Retry / Backoff → 초과 시 DLT
3	Consumer 이후 비지니스 로직 실패 유형1	의도된 예외로 인한 실패(잔액 부족 등)	Saga Pattern (보상 트랜잭션 수행)
4	Consumer 이후 비지니스 로직 실패 유형2	의도하지 않은 로직 오류(버그 fix 필요할 경우)	command payload 저장 → 코드/Data 수정 후 명령 재실행

  ※ 1번, 3번의 경우 10장에서 이미 다룬 내용이므로 생략.

 

3. Consumer 처리실패 시(표 2번 항목)

    : Spring Kafka를 이용하여 처리 가능     

 

    [예시코드] 

@RetryableTopic(
    attempts = "3",
    backoff = Backoff(
        delay = 5000,
        multiplier = 2.0
    ),
    dltTopicSuffix = ".dlt"
)
@KafkaListener(topics = ["payment.success"])
fun consume(event: PaymentSucceededEvent) {
    deliveryService.create(event)
}

 

   - 재처리 했음에도 불구하고 DLT 로 넘어가는 요청건에 대해서는 스케줄러

      or 배치를 통해 주기적으로 DLT topic 을 scan 하여 메시지를 원래 토픽 or 재처리 가능한 topic 형태로 발행 필요 

   - 일시적인 서버 나 네트워크오류로 인해 발생한 내역이므로, data 수정이나 소스코드 수정이 별도 필요하지 않기때문!

   - 또한, 자동처리하게 개발함에 따라 개발자가 계속해서 운영단에 모니터링 및 대응하는 비용이 감소하게 됨.

   - 물론, 모든 consumer가 호출하는 비지니스 로직에는 멱등성 처리가 되어있어야 하고, 순서보장이 중요한 도메인에서는

      별도 추가 조치가 필요함)

 

4. Consumer 로직 이후 비지니스 처리실패 유형 2(표  4번 항목)

   - saga pattern 이 아닌 에러발생 부터 그 이후에 비지니스 로직까지 성공시켜야하는 내용

   - 여러번 재수행에도 동일한 오류 발생하게 됨(근본적인 로직오류가 해결되지 않았기 때문)

   - 이경우, 향후 오류 hotfix 후 재처리를 위해 어떤 payload 였는지와 이후 어떤 작업을 수행하면 되는지를

      db 에 저장함(로그 형태 저장해도 됨(이후 수동 재처리를 위한 목적))

   - 오류 수정 이후 스케줄러 또는 수동 커맨드 기능을 이용하여 재처리하여 후단의 정합성 보장 함.