올영매장은 MSA 환경에서 흩어진 도메인 데이터를 어떻게 연동했을까?

올영매장은 고객이 앱에서 가까운 매장을 찾고, 매장별 재고·행사·픽업 주문 현황을 확인하는 O2O 핵심 서비스다. Phase 1과 Phase 2를 거쳐 고도화해 왔고, 최근에는 Phase 3인 매장 행사 및 프로모션 개편까지 마쳤다.

MSA 환경에서는 스토어 스쿼드, 쿠폰증정 스쿼드, 주문결제 스쿼드가 각자 다른 도메인 데이터를 관리한다. 그래서 단순히 API만 붙이는 방식이 아니라, 사용처, 변경 특성, 라이프사이클을 기준으로 어떤 연동 방식을 쓸지 먼저 결정했다.

오프라인 프로모션 데이터는 변경이 적고 시작일과 종료일이 명확한 데이터였다. 트래픽이 몰려도 빠르게 응답해야 했기 때문에, 매번 API를 호출하는 방식이나 1일 1회 S3 저장 방식은 제외하고, 필요 시 API 호출 + Redis 캐시를 쓰는 Cache-Aside 패턴을 택했다.

이 방식은 갱신이 필요한 시점에만 원본 API를 호출하고, 결과를 Redis에 저장해 재사용한다. 주기 배치로 종료된 프로모션을 자동 삭제하고, 운영 중 변경된 데이터도 캐시 갱신으로 반영해 효율성, 안정성, 정확성을 함께 확보했다.

반면 픽업 주문 데이터는 주문 취소나 준비 완료 같은 상태 변경이 잦고, 상품 정보와 금액, 고객 정보까지 포함한 무거운 데이터였다. 단순 캐시만으로는 최신성이 떨어질 수 있고, 매 요청마다 API를 때리면 제공 서버 부하가 커지기 때문에 다른 접근이 필요했다.

여기서는 Kafka Event-Driven + Redis Key 캐시 하이브리드를 적용했다. 주문 상태가 바뀌면 Kafka 이벤트를 받고, 올영매장 서비스는 그중 회원번호·주문번호 같은 최소 식별자만 Redis에 저장한다. 고객이 픽업 대시보드에 들어왔을 때 Redis에 Key가 있는 경우에만 API를 호출해 상세 데이터를 가져오므로, 불필요한 호출을 줄이면서도 최신 상태를 보여줄 수 있다.

핵심은 모든 데이터를 이벤트에 싣는 것이 아니라, "상태가 바뀌었다"는 알림만 받고 필요할 때만 조회하는 Event Notification 패턴을 썼다는 점이다. 이렇게 하면 Kafka 메시지는 가볍게 유지하면서도, 고객 화면에는 실시간에 가까운 픽업 현황을 제공할 수 있다.

결국 이번 개편의 교훈은 두 가지다.

• 데이터 특성이 연동 전략을 결정한다: 변경이 적은 프로모션은 Redis 캐시, 변경이 잦은 픽업 주문은 Kafka 이벤트 + Redis 캐시로 나눴다.
• 데이터 소비자가 연동 설계를 주도해야 한다: 데이터를 실제로 쓰는 쪽이 사용처와 라이프사이클을 가장 잘 아니, MSA에서도 소비자 관점이 의사결정의 중심이 되어야 한다.

같은 데이터 연동이라도 정답은 하나가 아니며, 결국 중요한 것은 데이터의 본질을 이해하고 그에 맞는 방식으로 조합하는 것이었다.