결제·취소 흐름 안에서 메시지를 바로 발행하고 물류 API 를 부르던 구조를, 주문과 주문 아웃박스를 한 MongoDB 트랜잭션에 저장하고 커머스의 배치 릴레이가 아웃박스를 폴링·CAS 선점해 Kafka 로 OMS 에 발행하는 구조로 바꾸는 설계다. 이미 운영 중인 조각과 앞으로 만들 조각을 나눠 적었다. 그리고 Kafka 를 고른 이유, exactly-once 대신 at-least-once + 멱등 소비를 고른 이유, CDC 를 쓰지 않은 이유, 장애 지점별 동작을 정리했다.
앱 첫 화면 API 가 1코어에서 초당 10건을 넘기면 무너졌다. Grafana 로 CPU 포화와 Mongo 전송량을 보고 Mongo 프로파일러로 요청 1건을 해부해, 병렬화 대신 DataLoader 배치·projection 으로 덜 읽고 2중 캐시로 안 읽게 바꾼 과정을 단계별 측정값과 함께 정리했다.
아임포트를 거쳐 KCP 로 결제하던 구조를 토스페이먼츠 직접 연동으로 바꾼 기록이다. 두 PG 의 결제건이 함께 살아 있던 전환 기간의 설계, 트랜잭션 없이 돈과 주문을 맞춘 장치, 승인 후 취소가 생기는 재고 구조, 무통장입금 만료가 석 달 반 동안 처리되지 않았던 사고를 정리했다.
RabbitMQ 알림 리스너가 CoroutineScope.launch 로 일을 넘기고 바로 반환해, 알림을 보내기 전에 ack 가 나가던 문제를 정리했다. runBlocking 으로 처리 후 ack 하도록 바꾸고, 그로 인해 생기는 재배달을 수신 원장과 업무 키로 막았다.
개발자 글쓰기 모임 3주차의 주제는 트랜잭션의 적용 사례와, 클린 아키텍처 적용 사례이다. 하지만 트랜잭션의 적용 사례는 2주 전에 트러블슈팅 내용으로 다루었었고, 클린아키텍처 적용 사례의 경우에는 글쓰기 모임 1주