Architecture
글 14개
Event-Driven · DLQ
실무의 이벤트 - 언제 꺼내고 무엇을 조심하나
패턴을 안다고 다 써야 하는 건 아니다. 이벤트 스키마라는 계약, 순서와 독약 메시지, 배포 후 안 보이는 흐름을 트레이싱으로 잇기, 그리고 애초에 이벤트가 답이 아닌 자리까지 짚으며 시리즈를 닫는다.
Event-Driven · Event Sourcing
상태 대신 이벤트를 진실로 - 이벤트 소싱
보통 DB엔 지금 상태만 남고 어쩌다 그렇게 됐는지는 덮어써져 사라진다. 상태 대신 일어난 일의 목록을 저장하고 필요하면 재생해 상태를 얻는 이벤트 소싱, 감사와 되감기가 공짜로 딸려오는 대신 치르는 값.
Event-Driven · CQRS
쓰는 모델과 읽는 모델을 가른다 - CQRS
쓸 때 좋은 데이터 모양과 읽을 때 좋은 모양은 다르다. 한 모델로 둘 다 하려면 한쪽이 고생한다. 명령과 조회를 아예 갈라 각자 최적의 모양을 갖게 하는 CQRS, 그 대가인 동기화 지연까지.
Event-Driven · Saga
흐름을 한곳에서 - 사가: 오케스트레이션
코레오그래피는 흐름이 코드 어디에도 없어 커지면 안 보인다. 지휘자 하나를 두고 각 단계에 명령을 보내 흐름을 한곳에 쥐는 오케스트레이션, 그리고 둘을 언제 고르나.
Event-Driven · Saga
여럿에 걸친 일을 잇는다 - 사가: 코레오그래피
주문 하나가 결제·재고·배송을 건드리는데, 서비스가 갈려 한 트랜잭션으로 못 묶는다. 여러 로컬 트랜잭션을 이벤트로 잇고 실패하면 보상으로 되돌리는 사가, 그중 코디네이터 없이 서로 반응하는 코레오그래피.
Event-Driven · Outbox
저장과 발행을 한 묶음으로 - 아웃박스
DB에 저장하고 이벤트를 발행하는 사이에 프로세스가 죽으면, 저장은 됐는데 발행은 안 된 어중간한 상태가 남는다. 두 시스템을 한 트랜잭션으로 못 묶는 문제를, 발행을 DB에 먼저 적어 푼다.
Event-Driven · Idempotency
같은 메시지가 두 번 와도 - 멱등 소비자
메시지 시스템은 확실히 전달하려다 중복을 만든다. 받는 쪽이 두 번 처리하면 결제가 두 번 된다. 처리한 걸 기억하거나 연산 자체를 멱등하게 만들어, 두 번 받아도 한 번처럼 삼키는 법.
Event-Driven · Architecture
이으면 생기는 문제들 - 이벤트 패턴 지도
쪼개고 비동기로 이으면 편해지는 대신 새 문제가 생긴다. 중복·발행 누락·분산 트랜잭션·복잡한 조회 - 벽마다 정해진 패턴이 있다. 그 이름들의 지도를 먼저 편다.
Architecture · Consistency
나누면 정합성을 잃는다
두 서비스의 숫자가 다르다. CAP는 셋 중 둘을 고르라는 말이 아니고, 실무의 선택은 이분법이 아니라 눈금이다.
Architecture · Event-Driven
Pub/Sub과 이벤트 기반
일을 시키는 대신 일어난 일을 알린다. 듣는 쪽을 몰라도 되는 대신, 흐름이 코드에서 사라진다.
Architecture · Message Queue
메시지 큐 - 기다리지 않게 만든다
지금 안 해도 되는 일을 쌓아두고 나중에 처리한다. 대신 실패가 나중에 오고, 중복이 오고, 순서가 흔들린다.
Architecture · Microservices
서비스끼리 어떻게 부르나
동기 호출은 가장 단순한 답이지만, 한 곳의 느려짐이 전체로 번지는 통로이기도 하다. 타임아웃·재시도·차단기로 그 통로를 좁힌다.
Architecture · Microservices
나누면 무엇이 달라지나
배포·장애·확장 단위를 갈라놓는 대신 네트워크가 끼어든다. 얻는 것과 새로 지는 비용을 나란히 놓는다.
Architecture · Monolith
모놀리스가 먼저다
한 덩어리로 만드는 건 아직 못 나눈 상태가 아니라 정상적인 출발점이다. 무엇이 쉬워지고, 언제부터 아파지는가.