1편에서는 @Transactional 안에서 Admin 서버로 직접 API를 호출하던 구조를 Transactional Outbox 패턴으로 바꾸고, AFTER_COMMIT 즉시 발송과 30초 폴링 재시도, 그리고 SKIP LOCKED 병렬 조회까지 구현했다. 마지막에

PeakTime 프로젝트에서는 사용자가 미션을 수행할 경우, Admin서버로 사용자 미션 통계 데이터를 API 요청을 보낸다. Admin 서버에서는 이 통계 데이터 Admin 에서 참조하는 데이터베이스에 저장한다. 문제 상황 PeakTime 에서 주요 기능은 미션을

기존 미팀 프로젝트에서는 미팀 자체 로그인과 소셜 로그인을 사용했지만 대학생 중심으로 페르소나를 좁히기 위해 세종대학교 포털 로그인을 통해서 학생인증을 하기로했다. 사용자는 미팀을 통해서 로그인을 하면 학교 API에 요청을 보내 학교 학생인지를 검증한다. 학교 API

write 쿼리(INSERT, UPDATE, DELETE)는 기본적으로 X락(Exclusive Lock)을 획득한다.데이터베이스에서 write 를 한 시점에 해당 row(레코드)에 대한 X Lock 을 획득한다. 이후 commit 일이 일어나기 전까지 소유하고 있다가

절기가 변경될 때마다 사용자에게 미션을 제공하고 알림을 발송하는 시스템오늘의 미션: 관리자가 절기별 15일치 사전 지정 (수동 큐레이션)개인화 미션: 태그 기반 매칭 (45개 미션 풀)LLM: 미션 생성 보조 (LLM이 리스트 생성 → 관리자가 선별)날씨 API: MV

기존 workflow는 기존 도커 컨테이너를 중단 후 ECR로 부터 pull 을 받아서 재실행하는 구조였다. docker stop meeteam-server || true 여기서 서비스가 중단되고 docker compose up -d meeteam-server

작년에 진행했던 프로젝트인 미팀을 몇개월 만에 다시 살려보고자 남아있는 팀원들이랑 방향성에 대해 논의해 보았다. 우선적으로 테스트 코드가 전무하니, 테스트를 구축과 동시에 프로덕션 코드를 리펙토링 하기로 하였다. 팀원이 많이 이탈했기 때문에, 팀원들이 작성한 코드마

MockitoBean 은 Application Context 이미 존재하는 빈이면 Mock 빈 으로 대체한다.존재하지 않으면 Mock 빈 으로 새로 등록한다.가짜 객체를 빈으로 등록하고,그 빈이 어떤 상태를 반환할지 정하면 된다.위와 같이 Mock 빈과 같은 Mock

미팀 프로젝트에서는 프로젝트 지원 후 지원자에게 SSE를 통한 알림을 전송해야 한다. 처음에 단순히, 아래와 같이 기능을 개발을 위해서 자연스럽게 다음과 같은 형태의 코드를 떠올렸다. 이 코드는 전형적인 동기 방식을 따른다. 동기 방식은 프로그램의 흐름을 직관적으로

LocalDate: 날짜만 표현할 때 사용한다 ex) 2013-11-21 LocalTime: 시간만을 표현할 때 사용한다. 시, 분, 초를 다룬다. ex) 08:20:30.213LocalDateTime: LocalDate 와 LocalTime 을 합한 개념 ex) 2

어떤 스프링 빈이 advisor1, advisor2 가 제공하는 포인트컷의 조건을 모두 만족하면 프록시 자동 생성기는 프록시를 몇개 생성할까?프록시 자동 생성기는 프록시를 하나만 생성한다.프록시 팩터리가 생성하는 프록시는 내부에 여러 Advisor등을 포함 할 수 있기

Virtual Thread 를 알아보기전에 기존의 Native Thread 의 context switching 이 발생하는 원리에 대해 알아보자기존의 JVM 에 존재하는 톰캣 스레드는 커널스레드와 1대1로 매핑되어 실행이 되는 구조이다.지금까지 CPU 코어가 톰캣 스레

SSE 는 그냥 단순하게 단향방 통신에서 사용된다 이정도만 알고 사용하였다.그저 HTTP에서 지원해는 기능? 정도 구나라고 생각했지만HTTP가 지원하는 기능이라기보다는HTTP 위에 정의된 이벤트 전송 규약(HTML5 표준)이라고 한다.SSE는 HTTP 위에서 동작하는

페이징 + 컬렉션 엔티티를 조회하려면 어떻게 해야할까데이터가 뻥튀기 되지 않게 할수 없을까???이렇게 order 를 기준으로 페이징을 할 경우는 어떻게 해야할까쉽게 말해서 Order 엔티티는 OrderItem 과 일대다 관계이기 때문에fetch join 을하고 페이징이

먼저 Fetch join 을 하지 않을때 어떤 문제점이 발생하는지 알아야 Fetch join 을 잘 사용할 수 있다여기서 먼저 Lazy 로딩이 뭔지 알아보자.엔티티를 접근해서 특정 필드에 접근하면 그때 연관관계에 있는 엔티티가 실제로 주입이 된다.즉 order.getM

CAS 연산을 사용하면 Lock 을 사용했을 때보다 성능상 좋았다.이런 결과가 왜 이러난 것일까?예를 들어 스레드 100개를 동시에 실행했을때 한 쓰레드가 Lock 을 소유하게 되면다른 스레드 99개는 전부 CPU 자원을 사용하지 않는 상태가 된다.(BLOCKING ,

CAS는 비차단 알고리즘의 대표격입니다. 스레드는 공유 변수의 예상 값(expected)과 실제 메모리 값을 비교하고, 같을 때만 새로운 값으로 교체합니다. 다른 스레드가 변수 값을 바꾸고 있더라도 해당 스레드는 대기(block)하지 않고 즉시 재시도(retry)할

Redis 단일 쓰레드에서 실행이 되기 때문에 동시성 문제에 대해 고민할 필요 조차 없다.레디스 주요 특징key-value로 구성된 단순화된 데이터 구조로 sql 쿼리 사용 불필요빠른 성능인메모리 NoSQL 데이터베이스로서 빠른 성능rdb는 기본적으로 disk에 저장이

아래 3개 (RedisTemplate, StringRedisTemplate, RedisCacheManager) 를 “무엇이고 / 언제 쓰고 / 어떻게 쓰고 / 서로 관계” 관점에서 처음 배우는 사람이 바로 그림 잡도록 정리했어.(핵심 → 비유 → 코드 → 선택 기준 순

각각의 스레드가 하는 작업은 크게 2가지로 구분할 수 있다.CPU-바운드 작업cpu의 연산 능력을 많이 요구하는 작업을 의미한다.이러한 작업은 주로 계산, 데이터 처리, 알고리즘 실행 등 cpu의 처리속도가 작업 완료 시간을 결정하는 경우다.예시 : 복잡한 수학 연산,