2편에서 저는 Orchestration 대신 Choreography Saga를 골랐습니다. 그러면서 이렇게 썼습니다."안무형의 최대 단점인 '흐름 추적 어려움'이 이 규모에서는 아직 크게 문제되지 않을 거라고 판단했습니다."판단 자체는 지금도 유지합니다. 서비스 3~4개에 흐름도 선형적이니까요. 그런데 글을 쓰고 나서 이 문장이 계속 걸렸습니다. "크게 문제되지 않는다"는 건 "문제가 없다"가 아니라, 빚을 나중에 갚겠다는 말이었으니까요.이번 편은 그 빚을 갚은 기록입니다. 결론부터 말하면 순서는 이랬습니다.보이게 만들고 (멈춘 사가를 관측)되살리고 (두 가지 실패 모드를 각각 복구)그 과정에서 버그 두 개를 잡았습니다. 하나는 배선이 조용히 어긋나 있었고, 하나는 가드를 한 곳에만 걸어둔 탓이었습니다...

presigned URL, 해시, 전자서명이 각각 보장하는 것 - 그리고 서명 파일을 왜 따로 두는가들어가며파일 업로드/다운로드 기능을 만들다 보면 "서명(signature)"이라는 단어를 하루에 세 번쯤 마주친다.presigned URL을 발급하면서 서명한다파일 해시를 붙이면서 이것도 흔히 서명이라 부른다설치 파일에 딸려오는 별도 파일도 서명이다같은 단어인데 셋 다 다른 것이다. 보장하는 범위가 다르고, 깨지는 조건이 다르고, 법적 의미도 다르다. 그런데 코드에서는 전부 sign, signature, verify라는 이름으로 등장하니 헷갈리기 딱 좋다.이 글은 파일 하나가 스토리지에 올라갔다가 클라이언트로 내려가는 흐름을 따라가면서, 그 과정에 등장하는 서명들을 하나씩 뜯어본다. 목표는 각각이 무엇을 ..

2편에서 재고를 Redis + Lua 스크립트로 원자적으로 차감해 오버셀을 막았습니다. 글을 쓰고 나니 스스로 이런 질문이 남았습니다."그럼 RDB로는 어떻게 하지? 그리고 Redis랑 뭐가 다를까?"예전 취업 준비 때 만든 프로젝트에서는 재고와 주문이 같은 DB, 같은 트랜잭션 안에 있어서 SELECT ... FOR UPDATE 하나로 끝났습니다. 그런데 이번 MSA 프로젝트는 재고(Redis), 주문(RDB), 결제(RDB)가 서비스별로 쪼개져 있어서 그때의 방식이 그대로 통하지 않았습니다. 그래서 이번엔 재고 차감을 Redis와 RDB 두 방식으로 다 만들어 같은 워크로드로 측정해봤습니다. 결론부터 말하면 RDB 쪽이 약 13배 느렸습니다. 그런데 이 글에서 하고 싶은 이야기는 "그러니 Redis가..

지난 글에서 저는 이렇게 예고하며 마무리했습니다."다음 글에서는 이 두 패턴 위에 쌓아 올린 Saga 패턴과, 보상 트랜잭션을 구현하며 실제로 만들었던 데이터 정합성 버그를 다뤄보겠습니다."1편(멱등성과 Outbox 패턴)에서 두 가지 함정을 막았습니다. Outbox 패턴으로 "DB 저장은 됐는데 이벤트가 안 나가는" 상황을, 멱등성으로 "같은 이벤트가 두 번 오는" 상황을요. 그런데 이 두 패턴은 결국 하나의 서비스가 다른 하나의 서비스에게 일을 넘기는, 딱 두 단계짜리 흐름을 안전하게 만든 것이었습니다. 현실은 더 깁니다. 주문 → 재고 차감 → 결제처럼 세 개, 네 개의 서비스를 거쳐야 하나의 "주문"이 완성됩니다. 그리고 중간의 어느 한 단계가 실패하면, 이미 성공해버린 앞 단계들을 되돌려야 합니..

요즘 EDA 토이프로젝트[링크]를 만들면서 공부 중인데, 만들면서 막히고 깨지고 다시 고친 것들이 생각보다 많아서 기록을 남기기로 했습니다."주문 저장하고 카프카에 이벤트 하나 보내면 되는 거 아닌가?" 이벤트 드리븐 MSA를 처음 설계할 때 누구나 이렇게 생각합니다. 저도 그랬습니다.그런데 이 한 줄짜리 직관 안에 숨어 있는 함정이 두 개나 있었습니다. 하나는 "저장은 됐는데 이벤트가 안 나갈 수도 있다"는 것이고, 다른 하나는 "같은 이벤트가 두 번 올 수도 있다"는 것입니다. 이 글은 Kafka 기반 이벤트 드리븐 주문 시스템 토이 프로젝트를 만들면서 실제로 부딪힌 트러블 슈팅, Outbox 패턴과 멱등성(Idempotency)을 코드와 함께 정리합니다. RDB와 메시지 큐를 같이 쓰는 시스템을 설..

이 글은 실무에서 직접 설계하고 전환한 경험을 바탕으로 작성했습니다.코드, API 스펙, 수치 등 일부 내용은 대외비 보호를 위해 각색되었으나, 기술적 맥락과 의사결정 흐름은 실제와 동일합니다.직접 구현했을 때 무엇이 문제였나직접 청크 업로드를 구현해보면 생각보다 처리해야 할 게 많다.CephFS를 쓰면 왜 직접 구현할 수밖에 없나CephFS는 파일시스템이다. Pod에 PVC로 마운트하면 /app/uploads 같은 로컬 디렉터리처럼 쓸 수 있다.그런데 이 구조에서 대용량 파일을 청크로 나눠 올리려면, 청크를 받아서 조립하는 주체가 반드시 백엔드여야 한다. CephFS 자체는 "파일을 나눠서 받아 조립해주는" 기능을 제공하지 않는다. 그냥 마운트된 디스크일 뿐이다.클라이언트 ──▶ 백엔드 (청크 수신 +..