NestJS

  • 캐시는 저장보다 삭제가 어렵다: NestJS 캐시 무효화 재설계

    NestJS 서비스에 Redis 캐시를 처음 붙일 때는 조회 메서드 앞에 데코레이터를 추가하는 일로 끝났습니다. 목록, 상세, 통계처럼 호출이 잦은 API의 응답 시간이 줄었고 데이터베이스 부하도 낮아졌습니다. 분산 락에서 사용한 데코레이터와 인터셉터 패턴을 캐시에도 적용했지만, 문제는 기능이 늘어난 뒤 나타났습니다. 프로젝트 이름을 수정했는데 상세 API는 새 값을…

    읽기 →

  • NestJS에서 데코레이터와 인터셉터로 분산 락 구현하기

    NestJS의 여러 endpoint에 같은 분산 락 패턴이 반복됐습니다. Redis에서 token을 얻지 못하면 429를 반환하고, 비즈니스 로직이 끝나면 소유 token을 확인해 lock을 해제하는 코드였습니다. 처음에는 service 메서드마다 이 코드를 작성했는데, 시간이 지나자 TTL과 key suffix, 오류 메시지, 해제 방식이 서로 달라졌습니다. 반복을 줄이기 위해 custom decorator와 global…

    읽기 →

  • Prisma의 과도한 Join이 프로세스를 죽였을 때 쿼리를 분해한 방법

    필요한 관계를 ORM의 include에 모두 넣어 한 번의 query로 완성된 응답을 만들었습니다. 코드 한 줄로 풍부한 객체 graph를 얻을 수 있었지만 여러 to-many 관계의 cardinality가 곱해지자 SQL 반환 행이 폭증했고, 이어서 객체 조립에 필요한 메모리도 함께 늘었습니다. 작은 개발 데이터에서는 드러나지 않던 이 문제가 운영 환경에서는…

    읽기 →