Topic
성능과 확장성
실제 트래픽을 고려한 캐시와 근거 중심의 성능 판단을 다룹니다.
페이징 카운트 쿼리가 데이터베이스를 느리게 하는 이유
정확한 전체 건수가 제한 조회보다 비싼 이유와 슬라이스, 캐시 메타데이터, 추정치 또는 요구사항 변경을 선택할 기준을 설명합니다.
좋아요 정렬을 위한 핵심 데이터와 집계 데이터 분리
집계 분리, 명시적인 최신성 기준, 비동기 갱신, 정합성 보정, 검색 경계로 좋아요 기반 정렬을 확장합니다.
작은 문제를 적은 자원으로 푸는 엔지니어링
현재 시스템의 한계를 측정하고 작은 문제를 비례 있게 해결하며, 근거가 생길 때 캐시와 분산 인프라를 추가합니다.
목록 좋아요 수는 단순한 조회부터 시작하라
현재 페이지의 좋아요만 제한적으로 조회하고, 카운터 컬럼이나 Redis는 규모가 커져 필요할 때 관리 비용과 함께 검토합니다.
도메인 학습과 기술 실험을 분리하는 두 가지 트랙
도메인 프로젝트는 익숙한 기술로 출시하고, 낯선 인프라는 최소 프로젝트와 성능 테스트로 따로 검증합니다.
아웃박스 폴링을 바꾸기 전에 측정하라
현실적인 부하로 아웃박스 폴링을 검증하고, 로그 테일링을 도입하기 전에 더 단순한 애플리케이션 전달 방식을 검토한다.
공통 집계와 사용자별 캐시 상태를 분리하라
리액션 상태를 재사용 가능한 조회로 조합하고, 한 회원의 개인 상태가 모두에게 노출되지 않도록 공통 합계만 분리해 캐시한다.
요구사항과 규모에서 시작하는 리액션 기능 설계
모호한 좋아요 요구를 정책으로 구체화하고, 데이터 증가량과 조회 비용을 계산해 리액션 모델과 변경 시점을 설계한다.
레거시는 점진적으로, 캐시는 운영까지 설계하라
레거시 경계를 신중히 고르고 작은 단계로 옮기며, DB 최적화와 배포 실패 조건을 이해한 뒤에만 공유 캐시를 추가하는 기준입니다.
실제 트래픽 모양에서 성능 테스트를 설계하라
부하 도구를 고르기 전에 트래픽 규모와 유입 모양을 추정하고, 여유를 정하며, 실제 위험이 있는 기능에만 검증 근거를 요구하는 방법입니다.
실제 트래픽이 없어도 대용량 시스템 대응은 연습할 수 있습니다
작은 서비스를 직접 운영하고 의도적으로 부하를 만들어 병목을 찾고 고친 과정을 보여주세요. 다만 부하 테스트를 운영 경험이라고 과장해서는 안 됩니다.