Case 02 / 05 · Async Backend

BAY Async

실패 가능한 주문·재고 작업을 API에서 분리하고, worker 경계와 운영 검증을 연결한 케이스.

문제

Problem

주문·재고 처리 흐름에 외부 알림과 재고 연동처럼 실패 가능한 작업이 섞여 있었다. 이 작업을 API 요청 안에서 끝까지 기다리면 외부 지연과 실패가 사용자 요청의 응답 경계까지 전파될 수 있었다.

작업을 API 밖으로 분리하는 것만으로는 충분하지 않았다. retry, 회귀 검증, worker까지 로컬에서 재현할 수 있는 개발 환경을 함께 만들어야 했다.

Decision

API의 응답 책임과 외부 작업의 완료 책임을 분리하고, 실패를 worker 경계에서 다룰 수 있는 흐름으로 만들었다.

API BoundaryAPI는 주문·상품·재고의 판정과 저장에 집중하고, 외부 상태를 기다리는 작업은 요청 처리 경계 밖으로 보낸다.
Worker FlowRabbitMQ·TaskIQ worker로 알림과 재고 연동을 분리해, API와 외부 작업의 실패 경계를 나눈다.
Regression Loop재고 retry와 API test, Docker CI, local setup을 함께 구성해 비동기 흐름을 반복 검증하고 협업자가 재현할 수 있게 한다.

System

주문·상품·재고 API에서 판단과 저장을 수행한 뒤, 외부 알림과 재고 연동은 queue 뒤의 worker로 넘기는 구조다.

주문·상품·재고의 판정과 저장을 API 경계에 두고 외부 작업과 분리.

알림과 재고 연동처럼 실패 가능한 작업을 message queue 뒤에서 처리.

재고 차감 실패를 API 재요청과 섞지 않고 worker retry 경계에서 복구.

API test, Docker CI, one-command local setup과 FE onboarding으로 흐름을 재현.

Operating Evidence

비동기 경계는 retry와 회귀 검증, 로컬 재현 절차까지 연결해 운영 가능한 형태로 구성했다. 성능이나 작업 성공률의 정량 결과는 확인된 근거가 없어 별도로 주장하지 않는다.