1. 아웃박스 폴링을 바꾸기 전에 측정하라

    현실적인 부하로 아웃박스 폴링을 검증하고, 로그 테일링을 도입하기 전에 더 단순한 애플리케이션 전달 방식을 검토한다.

  2. 공통 집계와 사용자별 캐시 상태를 분리하라

    리액션 상태를 재사용 가능한 조회로 조합하고, 한 회원의 개인 상태가 모두에게 노출되지 않도록 공통 합계만 분리해 캐시한다.

  3. 요구사항과 규모에서 시작하는 리액션 기능 설계

    모호한 좋아요 요구를 정책으로 구체화하고, 데이터 증가량과 조회 비용을 계산해 리액션 모델과 변경 시점을 설계한다.

  4. 레거시는 점진적으로, 캐시는 운영까지 설계하라

    레거시 경계를 신중히 고르고 작은 단계로 옮기며, DB 최적화와 배포 실패 조건을 이해한 뒤에만 공유 캐시를 추가하는 기준입니다.

  5. 실제 트래픽 모양에서 성능 테스트를 설계하라

    부하 도구를 고르기 전에 트래픽 규모와 유입 모양을 추정하고, 여유를 정하며, 실제 위험이 있는 기능에만 검증 근거를 요구하는 방법입니다.

  6. 실제 트래픽이 없어도 대용량 시스템 대응은 연습할 수 있습니다

    작은 서비스를 직접 운영하고 의도적으로 부하를 만들어 병목을 찾고 고친 과정을 보여주세요. 다만 부하 테스트를 운영 경험이라고 과장해서는 안 됩니다.