초기에는 Order 서비스에서 재고 감소 요청을 처리할 때, 분산 락을 적용하여 재고의 동시성 문제를 해결하려고 했습니다. 주문이 생성되면 Order 서비스에서 재고 감소 요청을 FeignClient를 통해 Product 서비스로 전달하면서 재고 감소 요청의 동시성을 제어하고자 했습니다.
그러나 이 방식은 재고 감소의 동시성 문제를 근본적으로 해결하지 못한다는 피드백을 받았습니다. Order 서비스에서 분산 락을 적용하는 것은 실제 재고를 줄이는 것이 아니라 재고 감소 요청을 중복으로 발행하지 않도록 제어하는 것이었습니다. 하지만 주문 생성과 이벤트 발행은 단순한 메시지 처리로, 동시성 문제를 일으키는 비즈니스 로직이 아니었습니다.
즉, Kafka를 통해 재고 감소 요청을 Product 서비스로 보내는 것 자체는 동시성 문제를 야기하지 않으며, Order 서비스에서는 이벤트 발행 역할만 수행하는 것이기 때문에 락을 적용할 필요가 없다는 결론에 도달했습니다.
이러한 피드백을 바탕으로 재고 감소 요청의 동시성 문제는 실제로 재고를 감소시키는 Product 서비스에서 해결해야 한다는 판단을 내렸습니다. 주문 생성 시 발생하는 재고 감소 요청의 트래픽 처리는 Order 서비스에서 Kafka 메시지 발행을 통해 처리되고, 실제 재고 감소는 Product 서비스에서 이루어지므로, 동시성 제어는 Product 서비스 내에서만 필요합니다.
책임의 분리:
Order 서비스는 주문 생성과 함께 단순히 재고 감소 요청을 Product 서비스로 전달하는 역할만 수행하고, 재고 감소와 동시성 제어는 Product 서비스에서 담당하게 되었습니다. 이는 서비스 간의 역할 분리가 명확해졌다는 점에서 SRP(단일 책임 원칙)를 준수하는 설계로 이어졌습니다.
재고 동시성 문제 해결:
실제 재고 감소는 Product 서비스 내에서 처리되므로, 동시성 문제가 발생할 수 있는 재고 감소 로직에 대해 Product 서비스에서 분산 락을 적용하여 근본적인 해결을 할 수 있었습니다.
확장성:
주문이 몰리는 상황에서 Order 서비스는 단순히 Kafka 큐에 메시지를 발행하는 역할만 수행하므로, 트래픽 증가에 유연하게 대응할 수 있었습니다. 결과적으로 Product 서비스는 재고 처리 로직에 집중할 수 있게 되었으며, 각 서비스가 본연의 역할에 충실하게 되어 시스템의 확장성이 향상되었습니다.
결과적으로, Order 서비스는 재고 감소 요청을 전송하는 역할에 집중하고, 실제 재고 처리 및 동시성 제어는 Product 서비스에서 담당하게 됨으로써 서비스의 책임 분리, 시스템 확장성, 재고 동시성 문제의 근본적인 해결을 모두 달성할 수 있었습니다.