Rush Deal 선착순 타임딜 프로젝트를 진행하면서,MSA 환경에서 주문 시스템과 포인트 시스템에 통신을 하는 가장 먼저 마주한 질문은 이것이었다."포인트 차감은 동기로 할까? 비동기로 할까?" "그렇다면 그럼 적립은?"단순히 “비동기가 좋다”는 접근보다는, 실제 비즈니스 요구사항과 기술적 트레이드오프를 면밀히 분석했습니다. 그 결과, 상황별로 통신 방식을 다르게 선택하는 하이브리드 전략을 채택하게 되었습니다. 이 글에서는 포인트 시스템을 구현하며 동기/비동기 통신 방식을 어떻게 결정했고, 각 선택이 어떤 영향을 미쳤는지에 대해 공유하려 합니다.1. 프로젝트 상황 Framework: Spring Boot 3.5.8 / Spring Cloud 2025.0.0Language: Java 21Architect..

RushDeal 프로젝트에서 로그아웃 API를 구현하던 중, 예상보다 흥미로운 고민이 생겼다.겉보기엔 단순한 기능이지만, 실제로는 "토큰을 검증해야 하는가, 아니면 멱등성을 보장하는 것이 맞는가"라는 선택의 순간이 있었다.이 글은 그 과정에서 했던 판단과 선택의 이유를 과정을 공유합니다. 1. 프로젝트 상황 및 초기 목표Framework: Spring Boot Language: Java 21 RushDeal 프로젝트의 인증·인가 시스템을 구성하면서, 그 중 한 기능으로 로그아웃 API를 설계하게 되었다.겉으로 보기엔 단순해 보이는 기능이었지만, 실제 구현 과정에서는 생각보다 많은 고민을 던져준 지점이었다. 1-1. 초기 구현처음 로그아웃 API는 JWT 발급 구조에 맞춰, 토큰을 검증한 뒤 블랙리스트..

실제 비즈니스의 흐름과 로직이 코드에 자연스럽게 녹아들도록 하는 방법론, 도메인 주도 설계(DDD, Domain-Driven Design)에 대해 학습하고 적용해 본 내용을 정리한 글입니다. 1. 등장배경1. 복잡성 증가처음에는 단순 CRUD 중심의 설계만으로도 충분했다.하지만 서비스가 성장하고 사용자와 기능이 늘어나면서 시스템은 점점 복잡해졌다.2. 기존 개발 한계과거에는 주로 기술 중심의 개발 방법론이 사용되었습니다. 이런 방법론은 기술적 요구사항을 중점적으로 다루지만, 비즈니스 규칙을 코드에 일관되게 담아내기 어려워졌다.이 과정에서 문제는 기술 부족이 아니라 도메인을 제대로 이해하고 표현하지 못했다는 점이라는 사실이 드러났다. 3. 필요성기획자, 운영자, 개발자가 같은 단어를 쓰면서도 서로 다른 의..

💬Rush Deal 선착순 타임딜 프로젝트 진행 중,API Gateway를 통해 User Service를 호출하는 과정에서 네트워크 에러가 발생했다. 1. 프로젝트 상황 및 초기 목표Framework: Spring Boot 3.5.8 / Spring Cloud 2025.0.0Language: Java 21 (Temurin)OS: Windows 11 (WSL2)Discovery: Netflix Eureka User Service를 띄우고 Gateway를 통해 요청을 하자 다음과 같은 에러 로그가 발생했다. io.netty.resolver.dns.DnsResolveContext$SearchDomainUnknownHostException:Failed to resolve 'DESKTOP-UO2KEQG.msho..

스파르타 내일배움캠프 Java 심화 4기, 'RushCrew' 팀의 타임딜 프로젝트를 진행하며 이벤트 스토밍을 적용했던 배경과 진행 과정, 진행 후 느낀점 기록입니다. 1. 도입 배경이전 물류 시스템 프로젝트를 개발할 때의 일이다. 기획서만 믿고 개발을 진행했는데, 막상 결과물을 통합하려는 순간 문제가 발생했다. (주문팀) "주문 쪽에서 허브(공급 업체)를 호출하는 거 아니었나요?" (배달팀) "아니죠, 배달 쪽에서 허브를 호출해서 데이터를 가져가는 구조로 이해했는데요?" 텍스트로 된 기획서의 문장 읽고 서로 주체와 객체를 다르게 해석한 것이다.이 '해석의 차이'로 인해 결국 재작업과 코드를 뜯어고치고 더 많은 시간을 썼던지.. 이러한 실수를 줄이기 위한 방법을 찾던 중DDD(Domain-Driv..

데이터베이스의 부하를 줄이고 응답 속도(Latency)를 개선하기 위해 캐시(Cache)는 선택이 아닌 필수이다.캐시가 무엇인지, 그리고 내 서비스 상황에 딱 맞는 캐싱 전략(Caching Strategy)은 무엇인지 정리 해보자. 1. 캐시(Cache)데이터의 원래 소스보다 더 빠르고 효율적으로 접근 할 수 있는 임시 데이터 저장소사용되었던 데이터는 다시 사용되어질 가능성이 높다는 개념을 이용하여, 다시 사용될 확률이 높은 것은 더 빠르게 접근 가능하자는 개념 파레토의 법칙 (80:20 법칙)"전체 요청의 80%는 상위 20%의 데이터에 집중된다."캐시는 이 법칙에 기반합니다. 모든 데이터를 캐시에 담을 필요는 없다자주 찾는(Hot) 20%의 데이터만 캐싱해도 전체 시스템 성능을 대폭 향상시킬 수 있다..

마이크로서비스 아키텍처(MSA)를 도입할 때 가장 먼저 마주치는 기술적 난관 중 하나는 바로 데이터 일관성(Data Consistency) 문제이다.모놀리식 환경에서는 하나의 데이터베이스에서 ACID 트랜잭을 통해 일관성을 보장 받았지만, MSA에서는 "Database per Service" 패턴으로 인해 데이터가 여러 서비스에 분산되어 있다.분산 환경에서 데이터 일관성을 유지하기 위한 전통적인 방법과, 현대적인 해결책인 SAGA 패턴에 대해 알아보자.1. 2PC (Two-Phase Commit)과거 분산 데이터베이스 환경에서 주로 사용된 방법으로,코디네이터(Coordinator)가 모든 참여자(Participants)의 트랜잭션 준비 상태를 확인하고 트랜잭션 커밋/롤백을 결정하는 방식 1단계: Pre..

💬 채용 공고나 기술 블로그를 보면 MSA(Microservices Architecture)가 마치 현대 개발의 표준인 것처럼 느껴질 때가 있다.반면 Monolithic Architecture는 왠지 낡고 피해야 할 레거시처럼 취급받기도 한다. 과연 MSA는 무조건적인 정답일까?두 아키텍처의 특징을 명확히 비교해 보고, 현업 개발자로서 우리가 가져야 할 아키텍처 선택의 기준에 대해 정리해 보려고 한다. 1. Monolithic Architecture모놀리식 아키텍처는 소프트웨어의 모든 구성 요소가 한 프로젝트, 한 패키지 안에 통합되어 있는 형태 특징: 강한 결합과 통합 모든 모듈이 하나의 Application 안에서 강한 결합을 가지며,데이터베이스 또한 하나의 DB에 모든 도메인(주문, 회원, 결제..