🫠 포스팅 길이가 길어지면 임시 저장 데이터가 자꾸 날아가버려서, 점진적으로 내용 추가 중입니다.✏️ 포스팅 길이가 너무 길어져 렉이 너무 심해진 관계로, User Status 관리, Redis Clustering 그리고 현재 포스팅에서 구현한 방식의 각종 문제점들에 대해서는 다른 포스팅에서 마저 작성하도록 하겠습니다.수정 일자내용`24.09.15• System Design• Message pub/sub• Proxy Server Routing`24.09.19• Authenticate (작성중)• Authorize (작성중)• 디자인 패턴을 적용한 ChannelInterceptor 리팩토링`24.09.29• Authenticate`24.10.01• Authorize Subscribe Interceptor..

📕 목차1. Web Socket2. Sub Protocol3. STOMP(Simple Text Oriented Messaging Protocol)1. Web Socket  [대규모 시스템 설계] 12장. 채팅 시스템 설계📕 목차1. 채팅 시스템2. 프로토콜3. 개략적 설계안4. 데이터 모델5. 상세 설계6. 개인적인 추가 고민1.  채팅 시스템 📌 과거와 현재 채팅 시스템 차이💡 책에 나온 내용은 아니고, 예전에 어딘jaeseo0519.tistory.com여기서 이어지는 내용.채팅 시스템 구현하다가, 우선 Web Socket 프로토콜에 대해서 명확하게 짚고 넘어가는 것이 좋다고 생각해서 작성.  RFC 6455: The WebSocket ProtocolThe WebSocket Protocol en..

📕 목차1. 채팅 시스템2. 프로토콜3. 개략적 설계안4. 데이터 모델5. 상세 설계6. 개인적인 추가 고민1.  채팅 시스템 📌 과거와 현재 채팅 시스템 차이💡 책에 나온 내용은 아니고, 예전에 어딘가에서 읽었던 내용인데 출처가 기억 안 나서 정확성이 떨어집니다.과거에는 채팅 프로그램을 위해 서버가 하는 일은 그저, 두 클라이언트의 연결을 돕는 일이 고작이었다.아마, stateless 환경의 HTTP 프로토콜 방식만으로는 한계가 있었기 때문이 아닐까 싶긴 한데, 그렇게 할 수밖에 없었던 이유를 당췌 못 찾겠다. 아무튼, 1:1 실시간 소통이 고작이라면 위 방식도 기능을 제공함에 있어 문제가 되진 않을 것이다. (데이터 보존 원칙같은 건 전부 무시하고, 순수하게 기능 제공 측면만을 고려했을 때)하지..

📕 목차1. 유일 ID 생성기2. 개략적 설계3. 상세 설계1. 유일 ID 생성기 📌 auto_increment는 답이 될 수 있을까?DB가 단일 서버라면 auto_increment가 답이 될 수 있다.하지만 사용자 트래픽이 높은 곳이라면 단일 DB만으로는 요구 사항을 감당할 수 없을 것이다.그래서 DB 서버를 분산화하면, 더 이상 auto_increment만으로는 유일성을 보장할 수 없기에 이를 동기화하는 작업이 필요한데 지연 시간(delay)을 낮추기가 매우 힘들어질 수 있다. 그리고 NoSQL을 사용한다면, 애초에 선택지가 존재하질 않는다는 문제가 존재한다. (여기서부터는 책에서 나온 내용이 이해가 안 가서, 추가 자료 조사와 추론을 기반으로 작성했습니다.) 🤔 DB를 다중화?샤딩을 통해 ma..