백엔드 서비스와 데이터 파이프라인 연결
3줄 요약
- 백엔드 서비스는 운영 DB에 쓰는 순간 끝나는 것이 아니라, event, outbox, consumer, mart, search, recommendation까지 이어지는 source가 된다.
- 핵심은 API transaction의 성공과 downstream 데이터 반영 성공을 분리해 보고, 이벤트 계약과 재처리 가능성을 명시하는 것이다.
- 데이터 팀 협업은 컬럼 전달이 아니라 business meaning, key, 지연 허용치, 취소/삭제 표현, 품질 rule을 함께 맞추는 일이다.
핵심 정리
API Transaction과 Event 발행 경계: API commit은 원천 상태를 확정하고, integration event 발행은 outbox나 CDC로 분리해 추적한다.Domain Event Integration Event 분리: domain event는 내부 모델의 사건이고, integration event는 다른 시스템이 장기간 의존하는 외부 계약이다.Reporting Search Recommendation 연동: 리포트, 검색, 추천은 같은 이벤트를 보더라도 freshness, 정합성, 재처리 요구가 서로 다르다.데이터 팀과 백엔드 협업: 데이터 팀에는 테이블 이름보다 event 의미, grain, 상태 전이, 삭제/취소 규칙, owner가 필요하다.기능 개발 시 데이터 영향 체크리스트: 기능 PR은 API, DB, event schema, mart, quality rule, backfill 필요성을 함께 확인해야 한다.- 이 챕터는 Web-Database의 query/transaction 설계를 넘어, 운영 데이터가 downstream 제품과 분석에 쓰이는 경계를 다룬다.
헷갈리는 지점
- API 응답 성공을 검색 색인, 추천 feature, 리포트 반영 성공으로 말하기 쉽다.
- API transaction은 원천 DB의 사실을 확정할 뿐이다.
- downstream 반영은 event 발행, consumer 처리, 재처리, 품질 검증으로 따로 관측해야 한다.
- domain event를 그대로 Kafka 외부 계약으로 내보내기 쉽다.
- 내부 도메인 객체는 자주 바뀌지만 integration event는 consumer 호환성을 지켜야 한다.
- 개인정보, 내부 enum, 임시 필드가 외부 계약으로 새어 나가지 않게 mapping 계층이 필요하다.
- 데이터 팀 협업을 SQL 요청으로만 이해하기 쉽다.
- 필요한 것은 어떤 row를 뽑을지가 아니라 어떤 사건이 어떤 의미이고 언제까지 믿을 수 있는지다.
- 취소, 환불, 삭제, 재처리 기준이 빠지면 mart와 feature가 조용히 틀어진다.
확인 질문
- API transaction과 event 발행을 같은 transaction처럼 설명하면 어떤 dual write 리스크가 생기는가?
- DB commit, outbox 저장, broker publish, consumer ack가 각각 다른 실패 지점이기 때문이다.
- 데이터 팀에 event schema 외에 어떤 업무 의미를 제공해야 하는가?
- key, grain, 상태 전이, 취소/삭제 표현, 지연 허용치, 재처리 범위, 품질 검증 기준이다.
- 기능 배포 전에 downstream 영향을 확인하려면 무엇을 체크해야 하는가?
- 새 필드와 enum, event version, consumer 호환성, mart 변경, quality rule, backfill 필요성이다.