개인 프로젝트 아키텍처 해부 — simple-schedule-app 전체 분석이 글은 개인 프로젝트 simple-schedule-app-be의 전체 코드베이스를 Claude Code로 탐색하고, 코드 한 줄 한 줄부터 아키텍처와 비즈니스 동작 방식, 도메인 설계까지 분석한 기록이다.프로젝트 개요Spring Boot 3.4.3 / Java 21 기반의 Gradle 멀티모듈 프로젝트다. 수강 신청 시스템을 주제로, course(수강 관리)와 notification(알림)이라는 두 개의 독립 애플리케이션이 Kafka를 통한 이벤트 드리븐 아키텍처로 연결된다.단일 레포지토리 안에서 마이크로서비스 아키텍처를 학습하는 구조다.simple-schedule-app├── common (공유 라이브러리, bo..

simple-schedule-app-be 전체 아키텍처 분석서분석 일시: 2026-04-03분석 커밋: c7dd6c95705a7c73fbf27554246ac370de112ad5브랜치: feature/query-performance-tuning목차시스템 전체 구조모듈 의존성 구조common 모듈 상세3-1. 엔티티 계층 구조 (Base Domain)3-2. 인증 (JWT Auth)3-3. 예외 처리 프레임워크3-4. Outbox 패턴3-5. Kafka 인프라3-6. AOP for Transaction3-7. 설정 클래스course 모듈 상세4-1. 엔티티 상속 계층 (Member / Schedule)4-2. 강의 수강 신청 워크플로우4-3. 특별 강의 (SpecialLecture) — Redis 동시성 제..

"과연 DB에 failed_notifications 테이블을 만들고, 실패한 알림을 이곳에 INSERT한 뒤 기존 notifications 테이블에서 DELETE 처리하는 것이 최선일까?"프로젝트를 진행하며 알림 발송 실패 처리에 대해 고민하게 되었습니다.보통 실패 처리를 논할 때"Redis의 지연 큐(Delayed Queue)를 쓰자" 혹은 "Kafka의 DLQ(Dead Letter Queue)를 쓰자"라고 결론을 내리기도 합니다.하지만 무턱대고 새로운 인프라를 추가한다는 것은관리 포인트 증가, 그리고 새로운 장애 전파 가능성의 증가를 의미하기도 합니다. 그래서 이번 글에서는 새로운 써드파티 인프라(Kafka, Redis 등)에 기대지 않고,현재 가진 기술(Spring, Java, MySQL, OS)을..

실패한 알림을 재전송할 때 FCM 알림만 다시 쓰게 할 수도 있고,아니면 기존의 SSE를 다시 활용하는 방식으로 다시 사용자가 실시간 접속 중인지 확인하고 SSE를 보내거나그렇지 않다면 FCM을 전송하는 방식을 활용할 수도 있습니다. 그리고 실패한 알림을 재전송하는 데에비동기로 처리할 수도 있고동기로 처리할 수도 있습니다. 이때, 비동기로 처리했을 경우 콜백 메서드를 등록해 둔다면또 다시 알림 전송에 실패했을 경우 스레드 정보가 달라질 수 있습니다.그러면 처음에 DB에서 찾은 실패 알림과 컨텍스트가 달라져서콜백 메서드가 DB에 실패한 알림을 update 하는 것이 아니라 insert 하게 됩니다. 또, 재전송하는 데에 있어서 구체적인 방식을 고민해 보자면 다음과 같습니다.트랜잭션 새로 전파하고 조건에..

이전에 실패한 알림에 대한 재전송 스케줄링 처리를 구현하고비동기 처리를 할 경우 새로운 스레드가 가지는 스레드 로컬에 대한 버그를 맞닥뜨리고트랜잭션 전파 범위에 대해 버그를 수정한 적이 있습니다. 그런데 비동기 논블로킹 처리를 하게 될 경우 트랜잭션 전파 범위에 따라서실패한 알림을 데이터베이스에서 조회하고 FCM으로 전송하는 과정에서 시간이 상당히 걸리게 된다면다른 모든 스레드들이 FCM 요청 말고 다른 작업을 수행하더라도 커넥션을 획득하지 못하는 상황이 발생할 수 있습니다. 물론 FCM이 수십 건이나 전송에 시간이 오래 걸릴 가능성은 그렇게 높지 않을 수 있습니다만,혹시라도 그럴 경우가 있을 수 있으니 이와 같은 상황을 테스트해 보고자 했습니다. 테스트 경로입니다. 다음은 스케줄링 메서드와 알림 전..

이전에 실패한 알림을 재전송하는 스케줄러를 등록한 뒤 데드락이 걸리지 않도록 트랜잭션 범위를 수정했습니다. 그런데 해당 동작이 정상적으로 수행하는지를 확인하려고 실제 애플리케이션을 동작시켜 보니(현재는 실제 FCM 토큰을 저장해 두지 않고 테스트용으로 저장해 둔 상태라 다시 실패하는 것이 정상입니다 ..)이렇게 기존의 실패한 메시지를 ID로 찾고 다시 실패한 다음 새롭게 레코드를 만들어 저장하고 있었습니다. @Scheduled(fixedDelay = 600000) // 10분마다 실행@Transactionalpublic void retryFailedNotifications() { List targets = failedNotificationRepository.findByRetryCountLessTh..

이전에 알림 모듈에서 알림 전송에 실패한 메시지를 데이터베이스에 저장하고주기적으로 재처리하는 스케줄러를 등록한 적이 있습니다. 스프링에서 @EnableRetry 설정값을 부여하면 retry 스케줄러를 등록하여 로직을 처리할 수 있습니다. 그런데 이때 주의할 게 있습니다. 여러 번 재시도를 하게 될 텐데 이때재시도를 처리하는 로직 자체에 비동기 처리를 하게 될 경우@Transactional 설정에 대한 주의입니다. 다음은 문제의 코드입니다.@Scheduled(fixedDelay = 60000) // 1분마다 실행@Transactionalpublic void retryFailedNotifications() { // ... List> futures = targets.stream() ..

### 이벤트를 분리하는 건 알겠는데 어떤 메시지를 발행해야 하지 ?이전에 '강의 모듈'과 '알림 모듈'을 분리하는 과정을 거쳤었습니다. 그런데 이벤트 기반 아키텍처(EDA)를 지향하는 데 있어서 카프카를 도입하고그 과정에서 어떤 메시지를 발행해야 하는지 ..구체적으로는 메시지에 어떤 내용을 담아야 좋을지에 대해서 고민했습니다. 이때, 제로 페이로드 방식과 이벤트 전달 상태 전송이라는 두 가지 방식 중 선택하고자 했습니다. 제로 페이로드 (Zero Payload)방식: 이벤트에 ID만 담아 보냅니다. 예를 들어,({ "type": "ACCEPTED", "enrollmentId": 123 })와 같이 최소한의 데이터만을 담습니다.여기서 카프카 컨슈머가 상세 내용을 알기 위해 API 등을 활용해서 도메인 서..