이번 주제인 메시지 큐와 이벤트 브로커는 일을 나눠서, 기다리지 않고 처리하는 도구다.메시지 큐는 프로젝트에서 "써봤다"고 말하기 쉬운 기술이지만, 막상 "왜 도입했나요?"라는 질문을 받으면 대답이 얕아지기 쉽다고 느꼈다. 그래서 이번에는 어떻게 쓰는지보다 왜 필요한지를 중심으로 정리해 보려 한다.1. 동기와 비동기: 주문 버튼을 누르고 몇 초씩 기다려야 할까?비동기 처리는 요청을 보낸 뒤 응답을 기다리지 않고 다음 작업을 진행하는 방식이다.동기 방식은 응답이 올 때까지 대기한 뒤 다음 작업으로 넘어간다. 사용자가 상품을 주문하면 서버는 이런 일들을 해야 한다.주문 생성 → 결제 처리 → 재고 차감 → 배송 요청 생성 → 알림/이메일 발송 → 주문 정보 저장 → "주문 성공!" 이 작업을 전부 순차적으로..

소개이 장에서는 분산 메시지 큐를 설계한다.메시지 큐의 이점:결합도 완화(Decoupling): 컴포넌트 간의 강한 결합을 제거해 각각 독립적으로 업데이트할 수 있다.향상된 확장성: 생산자 및 소비자는 트래픽에 따라 독립적으로 확장될 수 있다.가용성 향상: 시스템의 한 부분이 중단되어도 다른 부분은 계속 큐와 상호작용한다.더 나은 성능: 생산자는 소비자의 확인을 기다리지 않고 메시지를 생산할 수 있다.대표적인 메시지 큐 구현으로 Kafka, RabbitMQ, RocketMQ, Apache Pulsar, ActiveMQ, ZeroMQ가 있다.엄밀히 말하면 Kafka와 Pulsar는 메시지 큐가 아니라 이벤트 스트리밍 플랫폼이다. 하지만 두 유형의 기능이 서로 수렴하면서 메시지 큐와 이벤트 스트리밍 플랫폼의..

[가상 면접 사례로 배우는 대규모 시스템 설계 기초 2] 2장 - 주변 친구1장의 근접성 서비스는 사업장 위치를 다뤘다. 사업장 주소는 거의 바뀌지 않는 정적인 데이터였다. 2장의 주변 친구는 다르다. 사용자는 계속 움직이고, 위치는 몇 초 단위로 바뀐다. 자주 바뀌는 위치를 어떻게 실시간에 가깝게 친구들에게 전달할 것인가가 이번 장의 핵심이었다.1단계: 문제 이해 및 설계 범위 확정면접관과 합의한 조건은 다음과 같았다.'주변'의 기준은 반경 5마일이고, 이 값은 설정할 수 있다.거리는 친구 사이의 직선 거리로 계산한다. 강이나 도로 같은 장애물은 고려하지 않는다.전체 사용자 10억 명 중 10% 정도가 주변 친구 기능을 쓴다.사용자의 위치 이동 이력은 따로 보관한다. 나중에 머신러닝 등에 쓸 수 있다...

[대규모 시스템 설계 기초 2] 1장. 근접성 서비스근접성 서비스(Proximity Service)는 현재 위치를 기준으로 가까운 음식점, 호텔, 주유소 같은 시설을 찾아주는 서비스다. 지도 앱의 "내 주변 검색"이나 "가장 가까운 k개 주유소 찾기" 같은 기능이 여기에 해당한다.1단계. 문제 이해 및 설계 범위 확정최대 허용 반경은 20km 이다.사용자가 UI에서 검색 반경을 변경할 수 있다.사업장 소유주가 사업장 정보를 시스템에 추가/삭제/갱신할 수 있고, 다음날까지 변경된 정보가 반영된다.사용자의 이동속도는 빠르지 않아서, 상시적으로 페이지를 갱신할 필요는 없다.주어진 반경 내의 사업장만 대상으로 하고, 시간이 남으면 주어진 범위 안에 사업장이 많지 않은 경우를 어떻게 처리할지 고민해보자.요구사항요..