권한 검사를 매 요청 DB로 묻지 않게 — 권한 캐시
요청마다 조회되는 메뉴·기능 권한을 레디스에 캐시하고, 권한 변경 시 정확히 무효화하는 설계. 스테일 권한이 보안 사고가 되지 않게 하는 법.
키워드가 정확히 일치하지 않아도 의미로 글을 찾아줍니다. 모든 처리는 브라우저 안에서 일어나며 — 서버·API 키·외부 전송이 없습니다. (검색 모델은 처음 한 번만 받고 이후 캐시됩니다.)
매일 자동으로 바뀌는 복습 6선 — Network · OS · Algorithm · Database 각 1편 + 랜덤 2편.
요청마다 조회되는 메뉴·기능 권한을 레디스에 캐시하고, 권한 변경 시 정확히 무효화하는 설계. 스테일 권한이 보안 사고가 되지 않게 하는 법.

일관된 해싱은 노드 추가·삭제 시 키 이동을 어떻게 1/N로 줄이나. 해시 링·가상 노드·랑데부 해싱과 DynamoDB·Cassandra 샤딩을 애니메이션으로 정리합니다.
슬로우쿼리 로그 임계치 설정, p99 같은 백분위가 평균보다 중요한 이유, 평균이 숨기는 꼬리 지연을 찾아내는 방법을 다룬다.

검증 코드를 if문으로 도배하던 시절 컨트롤러에서 요청을 받으면 “이름은 비었나? 이메일 형식 맞나? 나이는 음수 아닌가?”를 일일이 if로 검사했습니다. 검증 로직이 비즈니스 로직과 뒤섞이고 API마다 중복됐죠. Bean Validation(Jakarta Validation) 은 이걸 애너테이션으로 선언적으로 바꿔줍니다. 그런데 실무에서 “분명 ...

“분명 @Transactional 붙였는데 롤백이 안 돼요” 트랜잭션은 @Transactional 한 줄이면 된다고 배우지만, 실무에선 “붙였는데 안 먹는다”를 자주 만납니다. 거의 전부 이 애너테이션이 어떻게 동작하는지를 모르면 못 피하는 함정입니다. 이 글의 목표는 하나입니다. @Transactional을 “DB를 묶어주는 마법”이 아니라 “T...
조인 비용을 줄이기 위한 의도적 비정규화, 중복 데이터를 동기화하는 비용, 읽기 모델을 분리하는 설계의 트레이드오프를 다룬다.

SQL을 한 줄도 안 썼는데 조회가 된다 Spring Data JPA를 처음 봤을 때 가장 신기했던 건, 인터페이스만 선언했는데 구현체 없이 동작한다는 점이었습니다. findByEmail이라고 메서드 이름만 지었더니 알아서 쿼리가 나가더라고요. 그런데 이 편리함을 “마법”으로 남겨두면, 실무에서 두 가지로 반드시 발목을 잡힙니다. (1) 분명히 값...
BETWEEN의 경계 포함 규칙, 23:59:59 누락, 함수로 컬럼을 감싸 인덱스가 깨지는 문제, 타임존 경계까지 날짜 범위 조회의 함정을 정리한다.
관계 데이터를 임시 스테이징 테이블에 모은 뒤 한 번에 반영하며 중복 INSERT 충돌을 막는 패턴. NOT EXISTS/ON CONFLICT, 임시 테이블의 수명과 동시성까지.