안녕하세요! 오늘은 마이크로서비스 환경에서 메시징 신뢰성을 보장하는 두 가지 핵심 패턴인 DLQ(Dead Letter Queue)와 Outbox 패턴에 대해 알아보고, 실제 프로젝트에 어떻게 적용했는지 공유하려고 합니다.문제 인식: "메시지가 사라지면 어떡하지?"저희 팀은 KimLeePark-Logistics라는 물류 시스템을 개발하면서 이벤트 기반 마이크로서비스 아키텍처를 구축하고 있었습니다. Order, User, Payment, Delivery 등 여러 서비스가 Kafka를 통해 통신하는 구조였죠.초기 설계를 하면서 두 가지 큰 고민이 생겼습니다:"주문을 DB에 저장했는데, Kafka로 이벤트를 보내기 전에 서버가 죽으면?""Consumer가 메시지를 받았는데 처리에 실패하면?"이 두 문제를 해결하..

들어가며이전 포스팅에서 Saga 패턴의 기본 개념에 대해 다뤘었는데, 실제로 설계를 진행하면서 오케스트레이션과 코레오그래피 패턴에 대해 더 깊이 이해하게 되었습니다. 이번 포스팅에서는 그 깨달음을 공유하고, 실제 프로젝트에 어떻게 적용했는지 소개하겠습니다.오케스트레이션 vs 코레오그래피 - 핵심 차이점오케스트레이션 (Orchestration)A → B → A오케스트레이션은 중앙 조정자(Orchestrator)가 있어서 흐름이 다시 조정자로 돌아오는 구조입니다. 마치 지휘자가 오케스트라를 지휘하듯이, 하나의 서비스가 전체 트랜잭션 흐름을 제어합니다.특징:중앙 집중식 제어명확한 트랜잭션 흐름 파악 가능복잡한 비즈니스 로직 처리에 유리코레오그래피 (Choreography)A → B → C코레오그래피는 각 서비..

MSA 환경에서 분산 트랜잭션 문제와 Saga 패턴1. 문제 상황 파악우리 프로젝트의 현재 상황현재 우리 프로젝트는 MSA 구조로 다음과 같이 구성되어 있습니다:1️⃣ 하나의 DB + 논리적 스키마 분리 (현재 개발 환경)PostgreSQL (logistics)├── order_schema├── inventory_schema└── delivery_schema✅ 별도의 트랜잭션으로 작동❌ Order 서비스가 롤백되어도 Inventory 서비스는 롤백 안 됨❌ DB가 다운되면 모든 서비스 마비2️⃣ 여러 개의 DB 인스턴스 (운영 환경 목표)Order DB → Order ServiceInventory DB → Inventory ServiceDelivery DB → Delivery Service✅ 별도의 트랜..

📝 MSA 프로젝트 설계 회의 회고오늘은 팀원들과 함께 MSA 기반 프로젝트의 핵심 아키텍처를 논의하는 중요한 회의를 진행했다. 여러 기술적 고민과 선택의 순간들이 있었고, 그 과정에서 많은 것을 배울 수 있었다.🔐 인증/인가 처리 - 가장 큰 고민회의 시작부터 가장 뜨겁게 논의된 주제는 바로 인증과 인가를 어디서 처리할 것인가였다.고민의 시작처음엔 두 가지 방향성이 맞섰다:Gateway에서 모든 URL별 권한을 매핑해서 처리할 것인가?아니면 각 마이크로서비스 내부에서 세부 권한을 체크할 것인가?그리고 만약 Gateway에서 인증만 처리한다면, 토큰을 그대로 넘겨줄지 아니면 Passport(통행권) 개념으로 유저 데이터만 넘겨줄지도 애매했다.튜터님의 조언과 최종 결정튜터님께 질문을 드렸고, 명쾌한 답..

📚 오늘 공부한 내용1. 팀 회의 진행항공권 예약 시스템 도메인 모델링에 대한 팀 회의를 진행했다.아래는 열심히 회의 한 내역입니다.2. Entity와 VO 구현 실습Ticketing 애그리거트 역할을 맡아 실제 코드로 구현했습니다:Entity: BoardingPass, Flight, PlaneTicket, SeatValue Object: Airline, Airport, Amount, FlightId, PassengerId 등🤔 학습 중 궁금했던 점Q1. @Embeddable과 @Embedded의 역할은?Q2. JPA를 통해 어떻게 DB에 저장되는가?Q3. PassengerId를 FK로 참조하지 않는데 어떻게 해결해야 할까?💡 학습 내용 정리1️⃣ @Embeddable과 @Embedded의 역할@E..