최신순 목록을 offset으로 조회하는 동안 새 데이터가 들어오면, 사용자가 보고 있던 페이지의 기준은 어떻게 달라질까?
발송 이력은 사용자가 목록을 조회하는 동안에도 계속 추가됩니다. 페이지 번호 기반 UI를 유지하면서 신규 데이터 유입으로 인한 중복·누락 체감을 줄이기 위해 최초 조회 시점의 정렬 기준을 앵커로 고정했습니다. 이 글에서는 문제 상황과 구현 흐름, 완전한 커서 페이징과의 차이를 정리합니다.
메타데이터와 발송 이력이 서로 다른 DB에 있을 때, 한 화면의 조회 결과를 어떻게 구성할 수 있을까?
레거시 SMS·알림톡 관리자 서비스를 마이그레이션하면서 하나의 관리자 서버가 서로 다른 두 DB를 함께 조회해야 했습니다. 이 글에서는 메타데이터 중앙화와 애플리케이션 레벨 조인을 선택한 기준, 구현 방식, 적용 가능한 데이터 규모를 정리합니다.
동기·비동기는 작업 완료를 누가 통지받는지, 블로킹·논블로킹은 호출한 스레드가 기다리는지를 설명하는 서로 다른 축입니다. 네 가지 조합을 비교하고 SMTP 작업을 요청 경로에서 분리한 사례에 적용해 봅니다.
이메일 발송은 외부 SMTP 서버의 응답을 기다리는 I/O 작업입니다. 초기 구현에서는 이 작업을 호출한 API 요청 스레드가 완료까지 기다렸습니다. 해결책을 선택하기 전에 동기와 블로킹을 같은 말처럼 사용하지 않도록 각각의 기준부터 구분했습니다.
Redis는 명령을 순차적으로 처리하는 싱글 스레드 모델로 잘 알려져 있습니다. 그런데도 여러 애플리케이션 인스턴스가 Redis를 함께 사용하면 동시성 문제가 발생할 수 있습니다.
"이메일 인증 코드는 왜 DB가 아닌 Redis에 저장할까?"
이메일 인증 코드는 짧은 시간 동안만 유효하고, 검증이 끝나면 즉시 제거해야 하며, 시도 횟수도 안전하게 제한해야 합니다. 이 글에서는 이러한 요구사항을 기준으로 관계형 DB와 Redis를 비교하고, TTL과 원자 연산을 적용할 때 주의할 점을 정리합니다.
관리자 페이지의 복잡한 검색 기능을 어떤 방식으로 구현해야 유지보수성과 성능을 함께 확보할 수 있을까?
다양한 필터 조건을 가진 검색 기능을 구현하면서 순수 JPA → Native Query → JPA Specification → MyBatis 순서로 접근 방식을 변경했습니다. 각 방식의 한계와 성능 측정 결과를 비교하고, 최종적으로 JPA와 MyBatis의 책임을 나눈 기준을 정리합니다.
안녕하세요!
신입 개발자 신강희입니다 😊