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

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

비관적 락, 낙관적 락, 분산 락을 다 써보고 나서야 정리했다지난 글 마지막에 커넥션 풀 데드락 얘기를 했다. 한 스레드가 커넥션 두 개를 잡으려다 서로 물려서 멈추는 상황이었다. 그걸 정리하다 보니 다음 질문이 자연스럽게 따라왔다. 애초에 락은 왜 걸고, 어떤 락을 골라야 하는 걸까.마침 내가 한 프로젝트들에 서로 다른 락이 들어가 있었다. 짠팟에서는 중복 챌린지를 막으려고 DB 비관적 락을 걸었고, Keepit에서는 AI 요약이 중복 실행되는 걸 막으려고 Redis 분산 락을 썼다. 당시엔 "이게 맞는 것 같아서" 골랐는데, 왜 그게 맞았는지 설명해보라고 하면 말이 막혔다. 그래서 이번에 제대로 정리했다.락은 왜 필요한가동시성 문제의 본질은 대부분 갱신 손실(Lost Update) 이다.스레드 A: ..