Pub-Sub, Observer & Event-driven Flows

1. Overview

발행-구독 및 이벤트 중심 흐름(Pub-Sub, Observer & Event-driven Flows, POE)은 호출자(Producer)가 다음 처리자(Consumer)가 누구인지 몰라도 시스템이 유기적으로 굴러가게 만드는 분산 시스템의 자율 지휘소입니다.

학습자는 단일 메모리 공간에서의 **옵저버 패턴(Observer Pattern)**이 어떻게 네트워크라는 물리적 한계를 넘어 발행-구독(Pub-Sub) 모델로 진화하는지 배웁니다. 특히, 하나의 메시지가 여러 구독자에게 동시에 터지는 **팬아웃(Fan-out)**의 물리적 부하와, '명령'이 아닌 '사실(Event)'을 중심으로 아키텍처를 구성하는 **이벤트 중심 아키텍처(EDA)**의 수리적 사상을 익힙니다. 이를 통해 서비스 간의 물리적 결합을 완전히 끊고, 기하급수적인 구독자 증가에도 끄떡없는 하이엔드 방송형 인프라 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Pub-Sub Mechanics: 토픽 기반 배포와 필터링의 물리적 알고리즘
• Observer Pattern Anatomy: 메모리 상의 객체 관찰과 상태 통지 수리 모델
• Fan-out Dynamics: 메시지 복제와 하드웨어 네트워크 대역폭 점유 물리학
• Event Flow Orchestration: 순차적 이벤트 체인과 복합 이벤트 처리(CEP)의 물리 흐름
• Push vs Pull Models: 구독자에게 밀어주기(Push)와 구독자가 당겨가기(Pull)의 수리적 차이

Out-of-Scope

• 메시지 브로커(Kafka, RabbitMQ)의 내부 저장소 물리 상세 (07-04-01 영역에서 분담)
• 리액티브 프로그래밍의 연산자(Operator) 상세 (07-04-03 영역에서 분담)

Boundaries

• POE vs. Message Brokers: 브로커(07-04-01)가 '메시지를 담는 병(Store)'에 집중한다면, POE는 메시지가 '어디로 흐르는지(Flow)'와 '어떤 의미로 쓰이는지(Context)'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "알림(Push Notification) 보내기"라 설명하는 것은 POE 학습이 아닙니다. 왜 발행-구독 모델에서 '결과적 일관성'이 시스템 전체의 물리적 정합성을 위협하는지 수리적으로 증명할 수 있어야 하며, **순서 보장(Ordering)**이 필요한 이벤트 흐름에서 '병렬 분산 처리'가 왜 하드웨어적으로 모순적인 목표인지 논증하지 못한다면 POE의 딜레마를 이해하지 못한 것입니다.

4. Prerequisites

• Network Layers & Protocols (Basic): 소켓 통신 및 HTTP 이해가 필수입니다. (08-01-02 기반 역량)
• Design Patterns for Distributed Systems (Recommended): 사이드카 및 분산 디자인 패턴 이해가 권장됩니다. (07-01-04 DPD)

5. Learning Map

1. The Watcher: 객체 내부의 변화를 조용히 지켜보고 알리는 옵저버의 기초 수리를 익힙니다.
2. The Broadcaster: 네트워크를 통해 전 세계 수만 개의 노드에 메시지를 뿌리는 물리적 확장을 배웁니다.
3. Fact over Command: "이것을 해라"가 아닌 "이 일이 일어났다"는 사실 기반의 물리 소통으로 전환합니다.
4. Autonomous Reaction: 미리 계획된 워크플로우 없이, 쏟아지는 이벤트에 시스템들이 각자 반응하여 거대한 가용성을 완성합니다.

6. Learning Topics

Basic

Core: 옵저버 패턴과 기초 메모리 이벤트 (Observer Pattern)

• Why to Learn: 프로그램 내부의 상태 변화를 실시간으로 전파하는 가장 기본적이고 효율적인 물리 기법이기 때문입니다.
• What to Learn:
  • Subject & Observers: 정보를 쥔 주체와 이를 바라보는 구독자들의 관계
  • Explicit Notification: 상태 변경 시 물리적으로 등록된 객체들의 메서드를 호출하는 수순
  • Lifecycle Management: 구독 해지(Unsubscribe)를 통한 메모리 누수 방지 물리학
• How to Learn:
  • 버튼 클릭 시 3개의 서로 다른 라벨이 업데이트되는 옵저버 코드를 작성하고, 메모리 할당량을 추적 실습
  • 동기(Synchronous) 옵저버 호출이 주 프로세스의 하드웨어 실행 성능을 얼마나 갉아먹는지 측정
• Implement: 리스트에 옵저버들을 담고 변화 시 notify()를 순회 호출하는 기초 Subject 클래스

Recommended

Core: 발행-구독 모델과 토픽 물리학 (Pub-Sub Dynamics)

• Why to Learn: 서버 한 대의 한계를 넘어 수만 명의 사용자에게 동시에 정보를 물리적으로 배달하기 위함입니다.
• What to Learn:
  • Broker-less vs Broker-based: 중앙 서버 유무에 따른 네트워크 패킷 흐름 차이
  • Topic-based Filtering: 메시지의 주제어($Key$)를 보고 하드웨어가 경로를 결정하는 물리 연산
  • Fan-out Physics: 하나의 페이로드가 100만 개로 복제되어 네트워크를 점유하는 과정
• How to Learn:
  • Redis의 PUBLISH/SUBSCRIBE 도구를 사용하여 수천 개의 채널에 메시지를 쏠 때의 시스템 지연 시간 측정 실습
  • 구독자가 늘어날수록 발행자(Publisher)의 CPU 점유율이 어떻게 물리적으로 변하는지 산출
• Implement: 메시지를 받아 등록된 채널(Topics)로 쏘아주는 간단한 PubSubBroker

Practical

Core: 이벤트 중심 아키텍처와 분리된 세상 (EDA Foundations)

• Why to Learn: 서비스 간의 호출 의존성을 물리적으로 완전히 끊어(Decoupling) 독립적인 성장을 하기 위해서입니다.
• What to Learn:
  • Command vs Event: '해라'와 '했다'의 수리 철학적 및 물리적 차이
  • Internal vs External Events: 시스템 안에서만 노는 이벤트와 밖으로 나가는 이벤의 구분
  • Event Store Physics: 이벤트가 흐른 궤적을 물리적으로 영구히 남기는 이유
• How to Learn:
  • 배달 앱에서 '주문 완료' 이벤트 하나에 결제, 알림, 배차 시스템이 각자 반응하는 물리 흐름도 설계 실습
  • 이벤트 기반 시스템에서 '디버깅'이 왜 하드웨어적으로 추적이 어려운지 사례 분석
• Implement: 이벤트 타입을 보고 각기 다른 처리기(Handler)를 구동하는 EventDispatcher

Advanced

Core: 복합 이벤트 처리와 지능형 흐름 (Complex Flows)

• Why to Learn: 낱개로는 의미 없는 이벤트들을 수리적으로 엮어 '사기 탐지'나 '예측' 같은 고차원 인사이트를 얻기 위함입니다.
• What to Learn:
  • CEP (Complex Event Processing): 초당 수만 건의 이벤트 중 패턴을 찾아내는 물리 엔진
  • Temporal Constraints: "10분 내에 로그인이 5번 실패했다"는 시간-이벤트 수리 결합
  • Event Semiaxis: 여러 이벤트가 모여 임계치($Threshold$)를 넘을 때의 가용성 판단
• How to Learn:
  • 주식 시장의 실시간 호가 이벤트들을 분석하여 '골든 크로스' 시점을 찾아내는 수리 알고리즘 설계 실습
  • 복합 이벤트 분석을 위해 하드웨어가 유보(Hold)해야 하는 이벤트 데이터의 물리적 메모리 크기 산출
• Implement: 특정 시간 내에 지정된 이벤트 시퀀스가 나타나면 알림을 주는 PatternMatcher

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Design / Software Structure and Architecture (Distributed patterns) — Structural context.
• [P1] CS2023 - SF/Systems Fundamentals (Events and notifications) — Core requirements.

Secondary

• [Event-Driven Architecture: Patterns and Practice] Fowler, E. — The foundational EDA guide.
• [Reactive Design Patterns] Roland Kuhn — Patterns for scalable event systems.

Industry

• [AWS: What is an Event-Driven Architecture?] — Cloud perspective on EDA.
• [Microsoft: Publisher-Subscriber Pattern] — Practical implementation guide.

9. Final Checklist

Primary

• '옵저버 패턴'이 단일 장치 내부에서 객체 간의 결합도를 어떻게 물리적으로 완화시키는지 설명 가능한가? (P2)
• '발행-구독(Pub-Sub)' 모델에서 브로커가 메시지를 물리적으로 복제(Fan-out)할 때의 하드웨어 리소스 변화를 기술할 수 있는 가? (P1)

Secondary

• '명령 기반' 호출과 '이벤트 기반' 호출이 비즈니스 로직의 '수정 용이성' 측면에 미치는 물리적 영향력을 소통 가능한가?
• 복합 이벤트 처리(CEP) 엔진이 이벤트 발생 순서가 뒤바뀌었을 때 생기는 수리적 오차를 어떻게 보정하는지 논증할 수 있는 가?

Industry

• 글로벌 커머스 시스템에서 '주문 완료' 이벤트를 통해 전 세계 리전에 재고 정보를 전파하는 물리적 시나리오를 제안할 수 있는 가? (SFIA)
• 시스템 부하 상황에서 중요도가 낮은 이벤트 구독자들을 일시적으로 하드웨어 망에서 분리(Drop)하여 생존성을 확보하는 절차를 분석할 수 있는 가?