스택큐힙리스트

1. ‘실시간’이 필요할 때 두 갈래 길알림·라이브 피드·채팅 같은 기능을 붙이다 보면 “Server-Sent Events(SSE)로 갈까, WebSocket으로 갈까” 갈등이 온다. 두 프로토콜은 모두 HTTP 위에서 동작하지만 성격이 확연히 다르다. 오늘 글에서는 “상황별 최적 선택법”을 정리한다.2. SSE — 단방향 스트리밍, 가볍고 자동 복구까지단방향: 서버→클라이언트 전용. 클라이언트가 뭘 보낼 일 없는 뉴스·주가·알림에 최적이다.HTTP 그대로: 별도 업그레이드 없이 text/event-stream으로 열려서 프록시·로드밸런서 호환성이 높다.자동 재접속 + 체크포인트: 브라우저 EventSource가 끊기면 재연결하고, Last-Event-ID로 놓친 메시지를 이어받는다.가벼운 서버 구현: ..

1. 문제 정의마이크로서비스가 늘어나면서 알림 메시지를 “한 번만, 정확히” 보내는 일이 점점 까다로워졌습니다. 실시간성이 중요하지만, 장애 · 스케일아웃 상황에서도 메시지 유실 없이 다시 처리할 수 있어야 하죠. Redis에는 두 가지 선택지가 있습니다.2. Redis Pub/Sub ― “속도 우선”휘발성(Volatile): 구독자가 없으면 메시지는 즉시 사라집니다. 실시간 채팅·라이브 지표처럼 “지금 안 보면 무의미”한 트래픽에 적합합니다.팬아웃 구조: 하나의 publish 로 모든 인스턴스가 동시에 수신 → 코드가 단순, 지연 주요 최신 기능: Redis 7.2 ‘Sharded Pub/Sub’로 클러스터 확장 시 레이턴시와 CPU 부하가 줄었습니다.단점: 장애 복구나 재전송이 필요하면 애플리케이션이..

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

Flutter로 첫 UI를 만들 때는 대부분 setState()만으로도 충분합니다. 하지만 앱이 커지고 여러 화면에서 같은 데이터를 써야 할 때, 코드가 점점 얽히는 경험을 하셨을 거예요. 그 지점을 깔끔하게 넘어가도록 도와주는 대표 솔루션이 Provider입니다. 오늘은 두 방법의 원리·탄생 배경·실전 사용처를 한눈에 정리해 보겠습니다.1. setState: 가장 원초적인 상태 관리setState(() { … })는 해당 StatefulWidget과 그 하위 트리 전체를 다시 빌드해 UI를 갱신합니다. 구현이 간단해 빠르게 화면을 그려 볼 때 탁월하지만,상태가 여러 위젯으로 퍼질수록 prop drilling(부모→자식으로 값 전달)이 복잡해지고,작은 변화에도 넓은 영역을 리빌드해 성능 저하가 나타나며,..