백그라운드 작업의 '정확히 한 번 실행'이 어려운 이유
백그라운드 작업을 큐에 넣었으니 한 번만 실행될 것이라고 믿으면 결제, 이메일, 재고 차감에서 중복이 생길 수 있습니다. 메시지는 중복 전달될 수 있고, 작업 완료 뒤 확인 응답이 사라질 수도 있습니다. '정확히 한 번'보다 중복이 와도 결과가 같도록 설계하는 편이 현
NOTES
시스템 아키텍처
모델을 만들고, 웹과 앱을 짓고, 업무를 자동화하며 확인한 것을 기록합니다. 통한 방법만이 아니라 통하지 않았던 시도까지 남깁니다.
TOTAL 5 · 시스템 아키텍처
DB 저장은 됐는데 이벤트는 안 갔다면: 아웃박스 패턴
주문을 저장한 뒤 메시지 브로커에 '주문 생성' 이벤트를 보내는 서비스가 있습니다. DB 저장은 성공하고 메시지 전송만 실패하면 다른 시스템은 주문을 모릅니다. 두 저장소를 한 번에 완벽히 쓰기 어렵다면 이벤트를 DB 트랜잭션 안에 함께 남기는 아웃박스 패턴을 검토할
주문은 취소됐는데 피킹은 진행 중이라면: 상태 충돌을 푸는 법
고객 주문 취소와 창고 피킹이 동시에 진행될 때 이중 환불·오출하를 막는 상태 전이 설계입니다.
실패 메시지를 다시 넣기 전에: DLQ 재처리를 안전하게 설계하는 법
죽은 편지 큐에 쌓인 메시지를 전부 재전송하면 같은 장애가 반복될 수 있습니다. 원인 분류, 멱등성, 소량 재처리, 관측 지표를 묶어 운영 절차를 만듭니다.
트래픽이 몰릴 때 큐만 늘리면 될까? 백프레셔와 부하 차단 설계
요청이 처리 능력을 넘는 순간 무제한 대기열은 장애를 늦출 뿐입니다. 유입률과 처리율, 제한 큐, 백프레셔, 재시도 폭풍, Load Shedding과 단계적 기능 저하로 핵심 서비스를 지키는 방법을 정리합니다.