개인적으로 동시성 제어에 대해 공부하던 중, 'DB 부하를 줄이기 위해 분산 락을 도입하는 것이 항상 최적의 성능을 보장할까?' 라는 호기심이 생겼고, 이 질문에 대한 답을 데이터 기반으로 찾고자 테스트를 설계하고 진행했습니다.먼저, 동시성 문제를 테스트하기 위해 JP

최근 한 기업의 백엔드 개발 과제를 진행하며 흥미로운 딜레마에 빠졌습니다. 과제의 요구사항에 따라 JPA로 엔티티를 설계하며, 저는 제가 사랑하는 원칙을 충실히 따랐습니다.ID는 데이터베이스가 생성하는 것, 고로 내 코드는 ID 없는 순수한 도메인 객체만 다뤄야 한다.

개발을 하다 보면, “이 코드… 또 복붙이네?” 하는 순간이 자주 찾아옵니다. 저도 마찬가지였고, 결국 그런 습관이 하나의 라이브러리를 만들게 했습니다. 이번 글에서는 제가 왜 공통 응답 템플릿과 예외 처리 로직을 라이브러리로 분리하게 되었는지, 어떻게 설계했는지,

이전 1편에서는 SSE(Server-Sent Events)의 개념과 단일 서버 환경에서의 적용 과정을 다루었습니다.이번글에서는 운영환경에서의 확장성과 안전성 확보를 중심으로, Redis를 통한 SSE 연결 관리와 Kafka를 통한 다중 서버 메시지 브로드캐스트 방식을

실시간 데이터 전송이 필요한 환경에서는 WebSocket, Long Polling, Server-Sent Events(SSE) 같은 기술이 활용됩니다. 이번 글에서는 SSE를 실전에서 적용하면서 경험한 것들을 공유하고자 합니다.SSE를 처음 접한 것은 이전에 진행한 끄

[이전 상황] 이전 1편에서는 쿼리 최적화를 통해 조회 성능을 크게 개선한 사례를 다뤘습니다. 쿼리 구조를 단순화하고 효율적인 접근 방식을 도입한 결과, 성능 지표에서 상당한 개선을 확인할 수 있었습니다. 하지만 실무에서는 조금 더 안전하고 빠른 조회를 요구하는