조용한 개발 노트

이 글은 Spring Cache 공식 문서와 실무에서 반복적으로 발생하는 장애 사례를 바탕으로, “처음엔 좋아 보였지만 결국 문제를 만든 캐시 설계 패턴”을 정리합니다.캐시는 대부분 의도는 선하고 결과는 나쁜 형태로 실패합니다. 이 안티 패턴들은 캐시를 아예 쓰지 말자는 이야기가 아니라, 언제 멈춰야 하는지를 알려주는 신호들입니다.안티 패턴 1. 캐시를 Source of Truth처럼 사용하는 경우가장 위험한 캐시 사용 방식입니다.DB보다 캐시를 먼저 신뢰캐시 없이는 정상 동작 불가처음엔 이렇게 시작합니다.조회 성능이 너무 중요하다캐시 히트율이 거의 100%다하지만 어느 순간,Redis 장애캐시 flushTTL 설정 실수중 하나가 발생하면, 서비스 전체가 마비됩니다.캐시가 없으면 서비스가 죽는다면, 그건..

이 글은 Spring Framework Cache Abstraction 공식 문서와 Spring Boot Cache 자동 설정 문서를 기반으로, 실무에서 가장 자주 마주치는 질문인 “Caffeine과 Redis 중 무엇을 선택해야 하는가”를 설계 관점에서 다시 정리합니다.들어가며Spring Cache를 도입할 때 가장 흔한 출발점은 다음과 같습니다.이미 Redis가 있으니까 캐시도 Redis로 쓰자분산 캐시가 로컬 캐시보다 항상 더 좋아 보인다하지만 Spring 공식 문서의 관점은 다릅니다. Spring Cache는 특정 기술을 권장하지 않으며, 캐시의 성격에 따라 구현체를 선택하라고 말합니다.이 글의 목적은 단순 비교가 아니라, “이 캐시는 어디까지 믿어도 되는가”를 기준으로 선택 기준을 명확히 하는 ..

이 글은 Spring Framework 공식 문서(Cache Abstraction)를 기반으로 캐시 환경에서 가장 자주 발생하는 동시성 문제와 @Cacheable(sync = true) 옵션의 실제 의미를 정리합니다.들어가며캐시를 도입하면 성능이 좋아질 것이라 기대합니다. 하지만 트래픽이 몰리는 순간, 캐시는 오히려 장애의 시작점이 되기도 합니다.캐시가 비어 있는 상태에서 동시에 수십 개의 요청이 몰림모든 요청이 DB를 동시에 때림캐시는 있는데 DB 부하가 더 커짐이 현상을 일반적으로 Cache Stampede라고 부릅니다.1. Cache Stampede란 무엇인가Cache Stampede는 다음 조건이 동시에 만족될 때 발생합니다.캐시 미스 상태동시에 여러 스레드가 동일한 키를 조회캐시를 채우는 비용이..

이 글은 Spring Framework 공식 문서(Cache Abstraction)를 기반으로 캐시와 트랜잭션이 함께 있을 때 실제로 어떤 순서로 동작하는지를 정리합니다. 특히 @Transactional과 @Cacheable, @CacheEvict가 겹칠 때 발생하는 오해를 호출 흐름 중심으로 설명합니다.들어가며캐시와 트랜잭션이 함께 등장하는 순간, 개발자는 본능적으로 이렇게 기대합니다.트랜잭션이 커밋되면 캐시도 반영될 것이다롤백되면 캐시는 자동으로 되돌려질 것이다하지만 Spring Cache 공식 문서는 이 기대를 명확히 보장하지 않습니다. 캐시와 트랜잭션은 서로 다른 책임을 가진 독립적인 메커니즘이기 때문입니다.1. Spring Cache는 트랜잭션을 “알지 못한다”공식 문서 관점에서 가장 중요한 전..

이 글은 Spring Framework 공식 문서(Cache Abstraction)를 기반으로 “왜 Spring은 Cache를 추상화했는가”를 설계 관점에서 정리합니다.들어가며캐시는 대부분의 서버 애플리케이션에서 성능 최적화의 마지막 카드처럼 사용됩니다. 하지만 Spring 공식 문서를 읽다 보면, 캐시는 단순한 성능 옵션이 아니라 애플리케이션 설계의 일부로 다뤄집니다.Spring은 왜 Redis, EhCache, Caffeine 같은 구체적인 기술 대신 Cache Abstraction이라는 계층을 만들었을까요?이 질문에 대한 답을 이해하지 못하면, Spring Cache는 곧 이렇게 사용됩니다.“조회 느리니까 @Cacheable 붙이자”“Redis 있으니까 그냥 캐시 쓰는 거지”이 글에서는 공식 문서가..