올
올리브영
June 30, 20251회
비동기 요청-응답 패턴으로 풀어낸 발주 서비스 개발기

간단 소개
올리브영 발주 서비스 개선 사례: Kafka 기반 비동기 요청-응답 아키텍처 구축을 통해 성능, 안정성, 확장성을 향상시키고, 중복 발주 문제를 해결했습니다.
AI Summary
- 발주 서비스 개선 배경
- 기존 발주 시스템의 느린 처리 속도와 새로운 백오피스 요구사항이 발생
- 동기식 처리 방식의 한계를 극복하고 비동기 아키텍처 도입 필요
- 비동기 요청-응답 아키텍처 구축 과정
- API Polling 방식의 한계: Kafka의 at-least-once 특성으로 인한 중복 메시지 처리 문제 발생
- ReplyingKafkaTemplate 방식의 한계: 메시지 유실 가능성으로 인한 재처리 및 중복 발주 우려
- API + Kafka 하이브리드 방식 채택: 요청은 API, 응답은 Kafka Consumer로 분리하여 안정성과 확장성 확보
- 최종 아키텍처 및 성과
- CORRELATION_ID를 활용하여 요청-응답 연결, DltListener + Reply Message 전략으로 예외 처리
- 평균 처리 속도 향상 및 백오피스 확장성 확보
- 비동기 요청-응답 패턴을 통해 대규모 백오피스 시스템의 성능, 안정성, 확장성 개선
Next Feeds

C++에서 안정적인 멀티 스레드 코드를 위한 스레드 안전성 개념 정리
C++ 멀티 스레드 환경에서 스레드 안전성을 확보하기 위한 핵심 개념(데이터 레이스, 연산 간 선후 관계, 기본 스레드 안전성)을 설명합니다.
데이터 레이스스레드 안전성동기화atomicmutex
2025. 6. 30.
Naver d2

Thread-safety in C++
C++ 멀티 스레드 환경에서 안정적인 코드 작성을 위한 스레드 안전성 개념 (Data race, Basic thread safety, 동기화)을 설명한다.
Thread-safetyData raceSequenced-beforeSynchronizes-withstd::atomic
2025. 6. 30.
Naver d2

기업간 전자 문서 교환을 위한 AWS상에서의 EDI처리 자동화
AWS 서비스를 활용하여 기업 간 전자 문서 교환(EDI) 처리를 자동화하고, 비용 절감 및 효율성을 향상시키는 솔루션을 제시합니다.
EDIAWS자동화HIPAAB2B Data Interchange
2025. 6. 30.
AWS

LLM 그 이후: A2A의 멀티에이전트 오케스트레이션 시대
A2A와 MCP 프로토콜을 통해 멀티 에이전트 시스템의 협업과 외부 도구 연결을 표준화하고 AI 오케스트레이션을 실현합니다.
A2AMCP멀티 에이전트오케스트레이션LLM
2025. 6. 30.
교보dts

SK ICT Family사 테크 블로그 총정리 (2025년 버전)
SK ICT Family사 테크 블로그들을 소개하고, 개발자 소통 및 기술 공유를 장려하며, SK AX, 원스토어, SK쉴더스 블로그가 추가되었습니다.
테크 블로그SK ICT개발자기술 공유DevRel
2025. 6. 29.
skplanet

서비스 조직에서 Kafka를 사용할 때 알아 두어야 할 것들 (3)
Kafka 클라이언트의 클러스터 상태 파악 방법, metadata 교환 메커니즘, NAVER ENGINEERING DAY를 소개합니다.
Kafkametadata클러스터브로커NAVER ENGINEERING DAY
2025. 6. 27.
Naver d2