[기획] BFF에서의 필터링 전략과 정합성 보장 설계의 관해

BFF에서의 필터링 전략과 정합성 보장 설계

들어가며

BFF(Backend For Frontend)는 단순 API Gateway가 아니다.
모바일, 웹, 관리자 등 다양한 클라이언트의 요구를 반영하고
서비스 전반의 정합성과 일관성을 설계하는 중심 허브가 된다.

이 글에서는 다음 두 가지를 중심으로 설명한다:

• 1부: 필터링/정렬/페이징 대응 전략 (조회 성능 개선 중심)
• 2부: 분산된 서비스 간 정합성 보장 및 오류 복구 설계

---

1부: 정렬·필터링·페이징의 현실적 해결

상황

"댓글 수가 많은 게시글을 최신순으로 정렬해줘"

• 댓글 수는 comment 모듈에서 관리
• 게시글 메타는 article 모듈
• 썸네일은 image 모듈

즉, 댓글 기준 정렬 → 게시글 정보 조회 → 이미지 로딩
→ MSA 구조에서는 이것만으로 3~4개의 요청이 필요

문제

• API 호출 병목
• 정렬 기준과 데이터 위치가 분산됨
• 조회 성능 저하, 비용 증가

---

해법: 반정규화 + 조회 전용 테이블

정렬, 필터링 기준 데이터를 게시글 DB에 미리 포함시킨다

예: comment_count, view_count, like_count

@Entity
public class Article {
    private Long id;
    private String title;
    private int commentCount;
    private int likeCount;
    private int viewCount;
}

정렬은 DB 내에서 index + ORDER BY 로 해결할 수 있음.

---

Redis 누적 + 주기적 DB 반영

• 요청마다 Redis INCR
• 5~10초마다 DB로 FLUSH (스케줄링)

→ 실시간은 아니지만 정렬 기준으로는 충분히 신뢰할 수 있음

---

DTO 설계 전략

클라이언트는 단순하게 요청하고,
BFF는 필요한 정렬 기준을 가공해서 전달한다.

// 앱에서 요청
{
  "sort": "most_commented"
}

// BFF → Article 모듈
{
  "articleIds": [123, 85, 17],
  "sortHint": "COMMENT_COUNT"
}

---

2부: 정합성과 보상 트랜잭션 설계

문제 정의

BFF에서 하나의 요청이 여러 모듈을 호출한다.
그 중 하나라도 실패하면 전체 요청을 "무효화"해야 한다.

→ 우리는 분산 트랜잭션이 없는 환경에서 이를 해결해야 한다.

---

방법 1: 보상 트랜잭션

• 실패가 발생하면 이미 실행된 작업을 되돌리는 API를 호출
• 예: 게시글 생성 후 이미지 업로드 실패 → 게시글 삭제 API 호출

POST /article
POST /image (실패)

→ DELETE /article

---

방법 2: 상태 기반 처리

• 모든 작업은 "PENDING" 상태로 시작
• 전부 성공하면 "COMPLETED"
• 실패 시엔 "CANCELLED"로 마킹

이 방식은 보상 API가 실패해도 데이터 정합성을 유지할 수 있다.

---

공통 요구: 요청 흐름 추적 가능해야 함

• 모든 모듈 요청은 requestId, transactionId 등으로 추적
• 장애 상황 시 rollback 대상 파악 가능

---

BFF의 책임

• 요청을 전파할 뿐만 아니라,
• 흐름을 통제하고, 실패 시 대응까지 책임진다

이걸 하기 위해선 BFF가 다음을 가져야 한다:

• 요청 순서 관리
• 상태 저장 or 이벤트 로그 저장
• 보상 트랜잭션 실행 조건 정의

---

마무리

• 정렬·필터링은 단순 로직이 아니다. 시스템 설계다.
• 반정규화, Redis, 조회 전용 테이블은 성능을 위한 기본 구성
• 보상 트랜잭션은 MSA 환경에서 반드시 고려해야 할 핵심 설계

---

요약

주제	해법
정렬 기준 데이터 분산	반정규화 + Redis 누적
조회 성능 저하	조회 전용 테이블 구성
분산 실패 처리	보상 트랜잭션 or 상태 기반 관리
BFF 역할 강화	정합성/흐름/복구 책임 분리