스택큐힙리스트

대규모 서비스가 두 세 대를 넘어 수십 대로 늘어나면, 알림 시스템이 가장 먼저 삐걱댑니다. 인스턴스 A에서 새 댓글이 등록됐는데 B에 붙어 있는 사용자는 아무 소식이 없거나, 같은 알림이 두 번씩 날아오곤 하죠. 분산 Observer 패턴을 Redis Pub/Sub로 풀면, 서버 수가 늘어나도 “한 번만, 정확히” 알림을 전송할 수 있습니다.1) Pub/Sub가 Observer를 분산으로 확장하는 방법Redis의 채널(topic)에 메시지를 Publish하면, 채널을 구독(Subscribe)한 모든 인스턴스가 동시에 이벤트를 받아옵니다. “발행자–구독자” 모델이니 Subject ↔ Observer 의존성이 사라져, 서버가 몇 대든 ‘알림 복제본’을 걱정할 필요가 없습니다. 2) 기본 흐름 한 줄 요약C..

변화가 생기면 알아서 퍼지게 하자! 이벤트 버스·알림 시스템의 기본 뼈대 Observer가 뭐길래?Observer(옵저버) 패턴은 “관찰 대상(Subject)”과 “구독자(Observer)” 사이에 느슨한 연결을 만들어,대상에게 변화가 생길 때마다 구독자에게 자동으로 알림을 뿌려 주는 행위(Behavioral) 패턴입니다.쉽게 말해 “뉴스레터 발송” 구조와 똑같습니다 — 발행인이 기사(상태)를 갱신하면, 구독자 메일함(반응)이 자동으로 울리니까요.언제 유용할까?이벤트 버스: Spring ApplicationEventPublisher처럼 서비스 곳곳에서 발생한 도메인 이벤트를 한 줄로 발행 → 여러 리스너가 동시에 처리UI 데이터 바인딩: Jetpack Compose·SwiftUI 같은 선언형 UI가 상태..

1. 왜 Strategy 패턴인가?“결제 수수료 정책이 또 바뀌었대요.”매번 if … else … 문을 고쳐 배포했다면 이제는 Strategy 패턴으로 갈아타 보세요.행위를 인터페이스(전략)로 분리해 두면 런타임에 원하는 구현으로 교체할 수 있어 코드 가독성·테스트 용이성이 모두 상승합니다. 이를테면 신용카드 → 계좌이체 → 간편결제 로직을 바꿀 때 클래스만 새로 만들어 DI(Container)가 끼워 넣어 주면 끝!2. 핵심 구조 (말로 툭 설명)Strategy: 알고리즘 규약을 담은 인터페이스ConcreteStrategy: 실제 알고리즘 클래스들Context: Strategy를 받아 행위를 위임하고, 필요하면 전략을 교체3. Kotlin 예제 – 결제 수수료 계산기// 1) 전략 인터페이스fun in..

1️⃣ Proxy 패턴, 한마디 정의‘Proxy(프록시)’는 대리인이라는 뜻 그대로, 원본 객체 앞에 서서 호출을 가로채거나 대신 처리하는 구조(Structural) 패턴이다. 클라이언트는 Proxy를 통해서만 원본에 접근하므로, 접근 제어·로깅·캐싱·지연 로딩 등을 가볍게 끼워 넣을 수 있다.2️⃣ 언제 써먹으면 좋은가?로깅·메트릭 수집 – 모든 서비스 메서드 앞뒤에 실행 시간을 재려 할 때보안·권한 체크 – 호출자 정보 확인 후 원본 메서드 실행 허용 여부 결정캐싱 – 동일 파라미터로 반복 호출 시 결과를 캐시해 DB 부하 절감가상 프록시(Virtual) – 고비용 객체를 ‘필요할 때만’ 초기화해 메모리 세이브이처럼 “추가 책임을 원본 코드 수정 없이 붙이고 싶다”는 요구가 나오면 Proxy가 정답이..