Live, Snapshot, Cache: revisiting the 3-way decision after 60 days of running it

개요

60일간 Live, Snapshot, Cache의 3가지 결정 방식을 적용한 경험을 바탕으로, 규칙 적용의 성공 사례와 예상치 못한 오류 발생 시의 대처 및 개선 방안을 논한다.

주요 내용

* 3-Way Decision Rule (Live, Snapshot, Cache): 데이터의 중복 저장 시 Live(실시간 조회), Snapshot(영구 저장, 재계산 불가), Cache(저장 및 새로고침 메커니즘 명시) 중 하나로 분류하며, 각 방식에 따른 구현을 다르게 한다.
* 규칙 적용 성공 사례:
* Snapshot: 가격 정책 변경 시 과거 데이터의 소급 재계산을 방지하여 회계 처리의 무결성을 보장했다.
* Cache: 데이터베이스 마이그레이션 시 새로 추가된 컬럼에 새로고침 메커니즘이 명시되지 않은 경우, 규칙에 따라 해당 변경 사항을 거부하여 데이터 불일치 가능성을 사전에 차단했다.
* Live: 사용자 요청 빈도와 데이터 조회량을 고려하여, 복잡한 집계 연산 대신 실시간 조회 방식을 선택하도록 유도했다.
* 규칙의 한계 및 오류 발생:
* used_at 컬럼은 Live(일시적인 사용 상태)로 분류되었으나, 토큰 객체를 조회할 때 Snapshot(영구적 식별자) 컬럼들과 함께 반환되면서 객체 수준에서의 일관성 오류가 발생했다.
* 규칙이 컬럼 단위로 데이터의 상태를 분류했으나, 여러 속성을 가진 객체를 재구성할 때 발생하는 동적인 변화를 충분히 고려하지 못했다.
* 개선 방안 (Hybrid Snapshot/Live Reset):
* Snapshot과 Live 속성을 모두 가진 객체를 다룰 경우, 조회 트랜잭션 내에서 Live 속성은 초기화하고 Snapshot 속성은 유지하는 패턴을 도입했다.
* 이 패턴은 기존의 3-Way Decision Rule(R6)을 보완하는 프로젝트 확장 규칙으로 정의되었다.

시사점

데이터 관리 규칙은 단순히 컬럼별 속성을 분류하는 것을 넘어, 객체가 가지는 다양한 속성들의 동적인 상호작용까지 고려해야 하며, 예상치 못한 오류 발생 시에는 기존 규칙을 확장하여 유연하게 대처하는 것이 중요하다.