"지금 잔액이 얼마인가?"이 질문에 답하는 방법은 두 가지입니다. 하나는 잔액을 컬럼에 저장해두고 읽는 것이고, 다른 하나는 거래 기록을 전부 더하는 것입니다.개발자로서 처음 드는 생각은 당연히 전자입니다. SELECT balance FROM account가 SELECT SUM(amount) FROM entries보다 빠르고 단순하니까요. 그런데 은행도, 카드사도, 결제 게이트웨이도 후자를 씁니다. 성능을 몰라서가 아닙니다.이 글은 그 이유에 대한 이야기입니다. 그리고 제 토이 프로젝트에 원장을 넣으면서, 원장을 만들었기 때문에 비로소 보인 구조적 결함 하나를 발견한 기록이기도 합니다.1. 잔액은 "상태"고, 원장은 "사실"이다차이를 한 문장으로 줄이면 이렇습니다.잔액은 덮어써지고, 기록은 쌓인다.bal..

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와 메시지 큐를 같이 쓰는 시스템을 설..