| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
Tags
- blockingqueue
- 장애복구
- 자연어캐싱
- 코사인
- 비동기처리
- 시맨틱캐싱
- OOP
- 배치처리
- DLT
- 메세지브로커
- redissearch
- 마케팅 #퍼플카우 #새스고딘 #혁신 #독서 #이북
- springboot
- retry
- 레디스스트림
- redisstreams
- 데이터유실방지
- SaaS
- 백엔드
- 메시지브로커
- 임베딩
- rdb
- 테스트코드
- 객체지향적사고
- jedis
- aof
- redis
- Kafka
- god object
- 레디스
Archives
- Today
- Total
pandaterry's 개발로그
[이벤트소싱] 이벤트(Event) VS 커맨드(Command) 본문

용어 정리 : 이벤트 vs 커맨드
이벤트(Event)
이벤트는 단순히 이걸 했다! 정도의 이력을 기록하는 용도이다. 어떠한 작용을 강제하는 역할을 하지는 않는다. 그래서 단순히 작업에 따라 event store에 event를 저장만 한다.
커맨드(Command)
커맨드는 말그대로 요청을 의미한다.
외부(External) 비동기 요청 : 마이크로서비스 환경에서 타 서비스에 작업을 요청할 수도 있고, 통신을 할 때 전달하는 객체 형태의 단위라고 보면 좋다.
내부(Internal) 요청 : 마이크로서비스 형태가 아니더라도, 하나의 서비스에도 여러 애그리게이트가 존재할 수도 있는데, 트랜젝션의 범주가 분리되는 기준으로 말이다. 그래서 다른 애그리게이트의 서비스에도 요청을 할 때 내부적으로 command를 사용할 수 있다.
사용 사례(Command의 즉각 응답 처리를 위해 인프라를 다르게 사용함)
일부 대규모 트래픽을 다루는 기업에서는 FeignClient나 gRPC를 통해 즉각적인 응답이 필요한 Command 요청을 처리하고 Kafka는 이벤트 처리용도로만 사용하기도 한다.
'개발 > 대규모' 카테고리의 다른 글
| 혼자서도 잘해요: 메세지 브로커 없이도 살아남은 Logging System 구조 이야기 (1) | 2025.06.18 |
|---|---|
| [이벤트소싱] SAGA Orchestration 패턴 + 트랜잭션 아웃박스 패턴 (0) | 2025.03.13 |