Queue, Stream, Event Bus의 Broker 내부 동작 차이에 따른 시스템 확장 전략

Queues vs Streams vs Event Bus: The Mental Model That Makes System Design Click

Joud Awad2026년 6월 22일2분intermediate

AI 요약

Context

Producer, Broker, Consumer로 구성된 유사한 추상화 구조로 인해 발생하는 Event-driven Architecture 설계 혼선 분석. Broker 내부의 데이터 처리 방식과 Consumer의 소비 모델 차이가 전체 시스템의 Scaling 방향을 결정하는 핵심 요인임을 식별.

Technical Solution

Queue: 단일 Consumer에 의한 일회성 소비 및 삭제 모델을 통한 Task 분산 처리 구조 설계
Stream: Offset 기반의 Log-structured 저장 방식을 통한 데이터 재생성(Rewind) 및 다중 Consumer의 독립적 읽기 속도 보장
Event Bus: Rule-based Routing 메커니즘을 통한 Producer-Consumer 간의 강력한 Decoupling 구현
Queue의 Worker 증설을 통한 수평적 확장과 Stream의 Bookmark 관리를 통한 상태 유지 확장 전략 구분
비즈니스 요구사항에 따른 선택: 중복 실행 불가 작업은 Queue, 시계열 데이터 분석은 Stream, 서비스 간 이벤트 전파는 Event Bus 채택

실천 포인트

1. 결제나 이메일 발송처럼 중복 처리가 금지된 작업인가? -> Queue 검토

2. 과거 데이터를 다시 읽거나 여러 팀이 동일 데이터를 서로 다른 속도로 처리해야 하는가? -> Stream 검토

3. 서비스 간 의존성을 제거하고 이벤트 발생 시 다수의 구독자에게 동적으로 전파해야 하는가? -> Event Bus 검토

태그

#Offset #Event-Driven Architecture #Message Broker #Decoupling #Scalability

원문 읽기