결제 완료, 멘토링 수락, 구독 활성화 같은 비즈니스 이벤트가 발생할 때마다 사용자에게 즉시 알림을 전달해야 했다. 초기에는 서비스 로직 내부에서 바로 알림을 생성하는 방식을 생각했지만, 이 방식에는 구조적인 문제가 있었다.

멘토-멘티 간 채팅 기능을 구현하면서 단순히 "기술 스택을 선택"하는 게 아니라, 각 선택에 트레이드오프가 있음을 직접 체감했다. 기술 선택의 이유, 실제 코드 구현, 그리고 남아 있는 한계까지 정리한다.

일반 포인트 충전은 사용자가 직접 결제창을 열고 카드 정보를 입력하는 1회성 흐름이다. 구독은 달라진다.

결제 시스템에서 웹훅은 다음과 같은 특성을 가진다:동일 이벤트 중복 전송순서 보장 없음지연 도착 가능네트워크 문제로 유실 가능\-> 이로 인해 다음 문제가 발생한다:웹훅이 몇 번 오든, 언제 오든, 어떤 순서로 오든 결과는 항상 동일해야 한다멱등키 기반 중복 처리 방지

환불 기능은 단순 상태 변경이 아니라, 서로 다른 시스템 간의 일관성을 맞춰야 하는 문제였다.내부 DB (결제 상태)포인트 시스템 (사용자 잔액)외부 PG 시스템 (PortOne 환불 API)\-> 이 세 시스템은 하나의 트랜잭션으로 묶을 수 없다.DB 트랜잭션 ⭕ (

결제 confirm 로직을 구현하면서 다음 3가지 문제를 동시에 해결해야 했다.외부 결제 API 호출이 포함됨트랜잭션 안에서 호출 시 DB 커넥션이 장시간 점유됨클라이언트가 전달한 금액은 신뢰할 수 없음실제 결제 금액과 다를 가능성 존재/confirm API 중복 호출

결제 confirm 로직을 구현하면서 다음과 같은 구조적 문제가 있었다.결제 검증을 위해 외부 API(포트원)를 반드시 호출해야 함동시에 결제 상태 변경, 포인트 충전 등은 DB 트랜잭션으로 묶어야 함외부 API 응답을 기다리는 동안 DB 커넥션 점유트랜잭션 길어짐 →

이번 과제는 단순 기능 구현이 아니라 다수 서버 환경에서 안정적으로 동작하는 시스템 설계가 핵심이라고 판단했다.그래서 다음 3가지를 중심으로 구조를 설계했다.동시성 제어데이터 일관성 보장확장 가능한 구조전체 흐름은 다음과 같이 구성했다.메뉴 조회 → Redis 캐시 적

동시성 제어를 위한 대표적인 락 방식으로는 낙관적 락, 비관적 락, 분산 락이 있다.각 방식은 락을 관리하는 주체, 보호 범위, 성능 특성, 그리고 적합한 적용 시나리오가 다르기 때문에 서비스의 구조와 트래픽 특성에 맞게 선택해야 한다.낙관적 락은 충돌이 적을 것이라고

Lettuce를 사용할 경우 분산 락을 구현하려면 다음을 직접 처리해야 한다.SETNX를 이용한 락 획득TTL 설정락 소유자 식별값 관리Lua 스크립트를 통한 안전한 해제락 재시도 로직즉, 락 구현에 필요한 세부 로직을 모두 직접 작성해야 한다.반면 Redisson은

1. MySQL 기반 Lock 구현 방식 Redis 대신 MySQL을 이용해 Lock을 구현하는 방법으로는 대표적으로 다음 두 가지가 있다. 1) JPA 비관적 락 (Pessimistic Lock) JPA에서 @Lock(LockModeType.PESSIMISTIC

낙관적 락은 데이터에 대한 충돌이 적을 것이라고 가정하고, 별도의 DB 락을 사용하지 않고 버전(version) 값을 통해 동시성 충돌을 감지하는 방식이다.JPA에서는 @Version 필드를 사용하여 구현할 수 있으며, 데이터를 수정할 때 기존 버전과 현재 버전을 비교

프로젝트에서 분산 락 처리를 비즈니스 로직과 분리하기 위해Spring AOP와 커스텀 애노테이션(@RedisLock)을 활용한 구조로 구현하였다.@RedisLock 애노테이션을 메서드에 선언하면, AOP의 @Around 어드바이스가 동작하여 다음 흐름을 수행하도록 설계

기존에 직접 구현했던 Servlet Filter(JwtFilter) + ArgumentResolver(AuthUserArgumentResolver) 기반 인증/인가 구조를 Spring Security 기반으로 전환했다.토큰 기반 인증 방식(JWT)은 유지하면서, 권한

오늘은 결제 프로젝트에서 Spring Security를 JWT 기반(stateless)으로 구성하고, Access Token / Refresh Token을 도입하면서 겪었던 이슈들과 해결 과정을 정리했다.CSRF 비활성화 (JWT는 보통 쿠키 세션 기반이 아니라서)Se

JWT는 기본적으로 Stateless 인증 방식이다.즉,서버는 토큰을 저장하지 않는다.토큰이 만료되기 전까지는 항상 유효하다.문제는 로그아웃이다.사용자가 로그아웃해도:이미 발급된 Access Token은만료 전까지 계속 사용 가능하다.그래서 “즉시 무효화”를 위해 블랙

오늘은 어드민 전용 API에 접근할 때마다요청 사용자 ID요청 시각요청 URL요청 본문(RequestBody)응답 본문(ResponseBody)을 AOP(@Around) 로 로깅하는 기능을 구현했다.어드민 사용자만 접근 가능한 특정 API에 접근할 때마다 로그 기록or

1. 문제 상황 일정 목록을 조회하면서 각 일정에 달린 댓글 개수를 함께 응답하는 기능을 구현했다. 초기 구현에서는 일정 목록을 조회한 뒤, 각 일정마다 댓글 개수를 따로 조회하는 방식을 사용했다. 기능은 정상적으로 동작했지만, 내부적으로 N+1 문제가 발생하고 있었다

SOLID 원칙은 시간이 지나도 유지보수와 확장이 쉬운, 그리고 이해하기 편하고 유연한 소프트웨어를 만들기 위한 다섯 가지 객체 지향 설계 원칙의 모음이다.객체 지향 프로그래밍을 하다 보면 코드는 점점 커지고, 기능은 계속 추가된다.이때 SOLID 원칙을 지키지 않으면

팀이 모두 같은 단어를 써야 헷갈리지 않습니다.Member(회원): 서비스에 가입한 사용자Admin(관리자): 운영 권한을 가진 MemberEvent(이벤트): 선착순 참여형 이벤트Participation(참여): 특정 Member가 특정 Event에 참여한 기록Win