reputation-pool 설계 기록

이 시리즈가 검증하려는 것

완성된 아키텍처를 사후에 설명하지 않습니다. 처음의 가정, 그 가정을 깨뜨린 테스트와 운영 제약, 수정된 계약과 아직 남은 한계를 실제 PR과 코드로 연결합니다.

1. 1편 · Lincheck 발행

   32스레드 테스트는 통과했지만 명세가 틀렸다

   Lincheck의 실패 trace가 fencing token, 리소스 선택과 block 경쟁의 실제 계약을 다시 쓰게 만든 과정입니다.

2. 2편 · Open-core 경계 발행

   코어를 SaaS에서 떼어냈더니 경계가 하나 더 필요했다

   JDK-only core와 SaaS를 나눈 뒤, 복사되던 gRPC adapter를 다시 공개 모듈로 추출한 과정입니다.

3. 3편 · 멀티테넌트 발행

   데이터를 나눴는데 장애는 함께 났다

   tenant별 상태·이벤트 격리에서 JVM 전역 예산과 요청율 제한까지, 공유 자원의 경계를 다시 나눈 과정입니다.

4. 4편 · 탄생 배경 운영 데이터 대기

   운영에서 reputation-pool이 필요해진 원인

   실제 운영 baseline과 실패 trace를 확보한 뒤, 리소스의 이력과 회복을 관리해야 했던 원인을 검증합니다.

5. 5편 · 수평 확장 발행

   왜 인스턴스를 두 개로 늘릴 수 없는가

   인메모리 lease·fencing·checkpoint의 정확성 범위를 추적하고 세 가지 상태 소유 모델을 비교합니다.

6. 6편 · Shadow mode 데이터 확보 후

   프로덕션 데이터로 판단 품질 검증

   실제 운영 데이터가 확보된 뒤 baseline과 shadow decision을 비교합니다.