토이프로젝트
1.백신 예약 프로그램
토이프로젝트를 하려고 생각하던 중 블로그에 맘에 드는 내용이 있어서 저도 만들어보려고 합니다참고프레임 워크 : Spring boot, ReactIDE : IntellijORM : JPA (Hibernate, Spring Data JPA)DBMS : MYSQL본인인증병원
2.토이프로젝트 - 데이터베이스
3.멱등성 처리 — DB Unique 제약으로 중복 이벤트 막기
지난글에서 Outbox 패턴의 한계를 다루면서 이런 얘기를 했다.Outbox는 at-least-once를 보장한다. 같은 이벤트가 두 번 발행될 수 있다. Consumer 쪽 멱등성 처리가 최종 방어선이다.이번 글은 그 최종 방어선을 어떻게 구현했는지를 다룬다.Kafk
4.Redis Lua 스크립트로 재고 동시성 제어하기 — reserve / commit / release 3단계 설계
지난글에서 멱등성 처리를 다뤘다. 이번 글은 재고 동시성 문제를 다룬다.커머스 서비스에서 재고 관리는 동시성 문제가 가장 빈번하게 터지는 영역 중 하나다. 특히 한정 수량 상품에 동시 주문이 몰리면 재고보다 많은 주문이 생기는 오버셀링(overselling) 이 발생할
5.주문 만료 처리 — 낙관적 락으로 스케줄러와 이벤트 핸들러 충돌 막기
지난 글(만료 직전에 결제가 완료되면 스케줄러와 결제 핸들러가 동시에 같은 주문을 처리하려 할 수 있다. 이 문제는 @Version 낙관적 락으로 해결했다.이번 글은 그 충돌이 실제로 어떻게 발생하고, 어떻게 해결했는지를 다룬다.주문이 생성되면 결제가 완료될 때까지 재
6.Redis 클러스터 도입기 — WSL2, 클러스터 초기화, 그리고 전체 컨테이너화까지
Redis 단일 인스턴스의 한계를 인식하고 클러스터로 전환하기로 했다. 그런데 막상 진행하다 보니 Redis 설정 외에도 개발 환경 자체를 뜯어고치게 됐다. 이 글은 그 과정을 순서대로 정리한 기록이다.처음엔 Windows에서 직접 개발하고 있었다. Docker Des
7.Outbox 패턴 직접 구현하기 — inFlight 카운터로 백프레셔 제어까지
지난 글(코드는 전부 이 프로젝트의 실제 코드다.📦 GitHub: eventful-commerce문제는 단순하다. DB 저장과 Kafka 발행을 동시에 원자적으로 처리할 수 없다.@Transactional이 끝난 순간 DB 커밋은 완료된다. 그 이후에 Kafka 전송
8.Redisson 분산락 도입기 — 그리고 Self-invocation을 피한 방법
지금까지 재고 동시성은 Redis Lua 스크립트로 제어했다. reserve → commit → release 3단계 구조로 오버셀링을 막았고, 낙관적 락으로 스케줄러와 결제 핸들러의 충돌을 처리했다.그런데 주문 취소는 다른 문제다.재고 예약은 단일 원자적 연산이라 L
9.정산·쿠폰 시스템을 만들기 위해 — 왜 이 순서로 개발했나
주문-결제-배송 플로우, Outbox 패턴, Redis 재고 동시성, 분산락까지 핵심 구조는 갖춰진 상태였다. 다음 목표는 두 가지였다.
10.정산 시스템 설계 — Kafka 이벤트, Spring Batch, 분산락까지
결제가 완료되면 판매자에게 돈을 줘야 한다. 그런데 결제 즉시 지급하지는 않는다. 실제 커머스에서 정산은 보통 이렇게 흐른다.취소나 환불이 생길 수 있기 때문에 당일 바로 지급하지 않는다. 하루가 지나 정산을 확정한 후 지급하는 구조다. 이 프로젝트도 이 흐름을 따랐다
11.API Gateway 설계 — JWT 검증을 중앙화한 이유
서비스가 3개를 넘어가면서 문제가 두 가지 생겼다.문제 1: 포트 파편화서비스 하나가 추가될 때마다 포트가 늘어난다. 외부에 서비스 포트를 전부 노출하는 것도 보안상 좋지 않다.문제 2: JWT 검증의 분산common-auth 모듈로 JWT 코드는 공통화했지만, 각 서