본문 바로가기
프로젝트 문의

Archive

이 주제의 글

Reliability & Observability

푸시 ‘발송 성공’인데 고객에게 알림이 안 오는 이유

푸시 미수신 진단은 요청 수락, 대상·큐, 사업자 접수, 기기 수신, 화면 표시와 상호작용의 증거를 나누어 원인을 찾는 과정입니다. 서버가 성공을 반환해도 기기 수신이나 화면 표시가 확인된 것은 아닙니다. 마지막으로 확인한 단계에서 다음 조사를 시작합니다.

Reliability & Observability

이미 구매한 고객에게 장바구니 메시지가 나가는 이유

구매 후 장바구니 메시지 오발송 방지는 여정 진입 자격과 발송 시점 자격을 따로 확인해 주문이 진행 중이거나 끝난 고객을 제외하는 설계입니다. 진입할 때 미구매였어도 대기 중에 구매하거나 계정을 바꿀 수 있습니다. 이벤트 지연과 중복, 식별 오류를 따로 확인해야 합니다.

Reliability & Observability

결제는 성공했는데 주문은 없다: 결제·주문 상태를 맞추는 설계

결제·주문 상태 정합성은 결제 사실과 주문·상품 제공 기록을 분리하고 확인된 증거로 누락된 단계만 복구하는 설계입니다. 외부 결제 승인과 자체 DB 저장은 동시에 완료되지 않을 수 있습니다. 결과를 모르는 상태를 실패로 바꾸면 중복 결제나 발급을 일으킵니다.

Topics

다른 주제

IXC 인사이트에서 다루는 다른 기술 영역입니다.

Software Quality & Release

요구사항, 검증 증거, 출시 판단과 품질 운영

Cloud & Infrastructure

워크로드 배치, 비용, 백업과 복구 설계

Security & Edge

API 자산, 보안 통제와 엣지 아키텍처

Engineering & Operations

배포, 이전, 인수와 운영 전환

Contact

도입 문의

글에서 다룬 기준을 귀사 운영 환경에 맞춰 점검해 드립니다.