오늘은 Replication이 구성된 PostgreSQL 환경에서 Spring Boot가 Master(Write) 와 Slave(Read) 를 자동으로 구분해 사용하는 방법을 설명해볼게요. Spring Boot는 기본적으로 다중 데이터소스를 자동 구성하지 않으므로, Master/Slave 분리를 위해 다음 작업이 필요합니다.Master / Slave 각각 별도의 DataSource 정의트랜잭션의 readOnly 여부에 따른 DB 라우팅AbstractRoutingDataSource를 활용한 동적 선택LazyConnectionDataSourceProxy로 실제 커넥션 생성 시점에 데이터소스 결정이 과정을 완료하면 Spring Boot는 읽기 요청은 Slave, 쓰기 요청은 Master 로 자동 라우팅하여 안..

안녕하세요! 최근에 본 한 유튜브 영상을 계기로 정리해보고 싶은 이야기가 있어 글을 쓰게 되었어요.아래 영상은 제가 개인적으로 존경하는 개발자 제미니님 채널의 콘텐츠인데요.영상을 보고 나서 “아… 나는 지금까지 너무 관성적으로 개발해온 건 아닐까?” 하는 생각이 강하게 들더라고요.그래서 이번 글에서는 ServiceImpl 패턴을 당연하게 사용하는 관행을 한 번 돌아보고자 해요.가볍게 읽어주세요. (영상을 함께 보시면 더 좋아요!) 이 글에서 이야기할 내용ServiceImpl 패턴이 무엇이며, 왜 스프링에서 거의 국룰처럼 쓰이게 되었는지이 패턴이 실제로 제공하는 장점은 무엇인지그런데도 왜 “무조건 쓰지 말자”는 말이 나오는지마지막으로, 언제 인터페이스를 도입하는 것이 진짜 가치 있는 선택인지결론부터 말씀드..

이길어때 프로젝트의 장소 상세 화면에서는 리뷰 개수, 댓글 수, 좋아요 수, 평균 평점 등 여러 집계 정보가 필요합니다. 그런데 이 값들을 계산할 때마다 여러 개의 COUNT 쿼리가 실행되면서 DB 부담이 점점 커지는 문제가 생겼습니다. 이 글에서는 이 문제를 Redis 캐싱으로 어떻게 해결했는지, 그리고 마지막에 Spring Cache 추상화(@Cacheable)를 적용해 비즈니스 로직을 깔끔하게 정리한 과정을 소개합니다. 이 글을 읽으면 다음 내용을 알 수 있을거에요Count 기반 데이터를 언제 캐싱하면 좋은지Spring + Redis로 Cache-Aside 패턴을 구현하는 방법Spring Cache 추상화를 활용해 캐시 로직을 서비스 코드에서 분리하는 실전 패턴 문제 상황: 장소 상세 화면에 반복되..

제가 개발 중인 이길어때 프로젝트는 최근 SNS 서비스 형태로 확장되고 있습니다.SNS라면 빠질 수 없는 기능이 바로 실시간 알림이죠.좋아요, 댓글, 팔로우 같은 사용자 행동을 바로 알려주면 서비스의 사용성이 크게 좋아지기 때문입니다이번 글에서는 Spring에서 SSE(Server-Sent Events) 로 실시간 알림 기능을 구현하는 방법과,운영 환경에서 실제로 마주쳤던 다중 서버 환경 문제를 Redis Pub/Sub으로 해결한 경험을 정리했습니다. 이 글을 읽으면 다음과 같은 내용에 대한 이해를 얻을 수 있을거에요 :)폴링 / 웹소켓 / SSE 중 알림 시스템에 적합한 방식 고르기Spring SseEmitter로 SSE 알림 구현하기다중 WAS 환경에서 SSE가 겪는 구조적 한계Redis Pub/Su..

스프링의 의존성 주입(DI)을 이해하려면 먼저 스프링 컨테이너(Spring Container) 가 어떤 역할을 하는지 파악하는 것이 중요합니다.스프링 컨테이너는 객체(Bean)를 생성하고 관리하며, 필요한 의존관계를 연결해주는 핵심 엔진입니다. 이번 글에서는 스프링 컨테이너의 기본 개념부터 시작해 BeanFactory와 ApplicationContext의 차이, 그리고 실무에서 ApplicationContext가 사실상 표준으로 쓰이는 이유까지 차근차근 살펴보겠습니다. 이 글을 읽고 나면 다음 내용을 이해할 수 있을거에요Spring Container가 무엇이며 어떤 역할을 하는지BeanFactory와 ApplicationContext의 기능과 차이점ApplicationContext가 실무에서 기본 컨테이..

Spring MVC로 개발하다 보면 HandlerMapping, HandlerAdapter, DispatcherServlet 같은 용어를 자주 마주하게 됩니다.하지만 DispatcherServlet이 컨트롤러를 호출하기까지 왜 두 단계를 거쳐야 하는지는 구조를 직접 들여다보기 전에는 쉽게 이해하기 어렵습니다. 최근 진행하고 있는 기술 스터디에서 Spring Web MVC의 요청 처리 흐름을 살펴보던 중“HandlerMapping이 이미 컨트롤러를 찾았는데, 왜 바로 호출하지 않을까?”,“그렇다면 HandlerAdapter는 어떤 역할 때문에 필요한 걸까?”라는 궁금증이 생겼습니다. 이 글을 그 질문에 대한 답을 정리하면서, Spring MVC 요청 처리 구조를 이해하는 데 도움이 되고자 작성해보았습니다...