System design

긴 URL을 짧은 코드(예: bit.ly/aZ8kQp)로 바꿔주고, 그 짧은 링크를 누르면 원래 URL로 보내주는 서비스다. 핵심은 두 가지: 짧은 코드를 안 겹치게 빨리 만드는 것, 그리고 리다이렉트(읽기)를 아주 빠르게 처리하는 것. 읽기가 쓰기보다 압도적으로 많은 전형적인 읽기 위주 시스템이다.

여러 대의 API 서버 앞에서 클라이언트별로 요청 속도를 제한해야 한다. 예를 들어 "사용자당 초당 100건"을 넘으면 429(Too Many Requests)를 돌려준다. 서버가 50대로 흩어져 있어도 카운트가 한 곳처럼 합쳐져야 하고, 이 판단은 모든 요청마다 1~2ms 안에 끝나야 한다.

오픈도어 같은 부동산 마켓에서, 사용자가 팔로우/저장한 집과 동네에서 일어나는 일(가격 인하, 새 매물, 내 오퍼 상태 변경, 투어 예약 확정)을 시간순 피드로 보여줘야 한다. 핵심 어려움은 "한 번의 이벤트(예: 인기 매물 가격 인하)를 그걸 저장한 수만 명의 피드에 어떻게 뿌리느냐(팬아웃)"다. 읽기가 쓰기보다 훨씬 많고, 약간 늦어도(몇 초) 괜찮은 대신 항상 빠르게 보여야 한다.

Opendoor 같은 부동산 마켓플레이스에서 사용자에게 알림을 보내는 시스템을 설계한다. "새 오퍼 도착", "가격 변동", "거래 단계 변경" 같은 이벤트가 생기면 푸시, 이메일, SMS로 알림을 보낸다. 핵심은 절대 같은 알림을 두 번 보내지 않으면서(중복 방지), 트래픽이 몰려도 안 죽고, 발송 지연을 짧게 유지하는 것이다.

사용자가 지도에서 한 지역을 보면서 "마이애미, 침실 3개 이상, 50만 달러 이하" 같은 조건으로 매물을 찾는 검색 시스템을 설계한다. 핵심은 지도 박스(위/경도 범위) 안의 매물을 필터 + 정렬 + 페이지네이션해서 빠르게 돌려주는 것이다. 가격이나 상태가 바뀌면 검색 결과에도 몇 초 안에 반영돼야 한다.

Opendoor 같은 부동산 마켓에서 집 한 채에 대해 오퍼(매수 제안)를 만들고, 보내고, 수락하고, 마감(closing)까지 가는 거래 흐름을 설계한다. 핵심은 "상태 변경은 단순한 필드 수정이 아니라 비즈니스 이벤트"라는 점이다. 돈이 걸린 거래라서 정확성(correctness)과 감사 추적(audit)이 가용성보다 더 중요하다.

Opendoor는 집주인이 주소를 넣으면 "우리가 이 집을 얼마에 살게요"라는 가격(오퍼)을 보여줘야 한다. 이 가격은 기준값 + 리노베이션 + 리스크 + 시장상황을 합쳐서 나오는데, ML 모델과 여러 외부 데이터(비교 매물, 시세)가 필요해서 계산이 무겁다. 핵심은 무거운 가격 계산을 사용자에게 보이는 오퍼 상태와 분리하고, 모든 가격을 버전으로 남겨서 "왜 이 가격이 나왔는지" 항상 설명할 수 있게 만드는 것이다.

단순한 get(key) / put(key, value) API 두 개만 제공하지만, 데이터가 한 서버에 다 안 들어가는 분산 키-값 저장소를 설계한다. 핵심은 수백 대 서버에 데이터를 어떻게 나누고(샤딩), 한 대가 죽어도 데이터가 안 사라지게(복제) 만드는 것이다. DynamoDB나 Cassandra가 실제로 이렇게 동작한다.

오픈도어는 집을 직접 사고판다. 집의 상태는 재고(인벤토리) 시스템에, 돈의 흐름은 재무 원장에 따로 기록된다. 따로 기록되는 두 시스템은 시간이 지나면 반드시 어긋난다 — 집은 팔렸다고 돼 있는데 입금 기록이 없거나, 금액이 다르거나. 이 어긋남을 매일 자동으로 찾아 심각도별로 분류하고, 사람이 처리할 것만 검토 큐에 올리는 시스템을 설계한다. 제조업의 재고-재무 대사(reconciliation)와 정확히 같은 모양의 문제다.

수백 명의 운영(ops) 인원이 같은 작업 보드를 보고 있다. 누군가 작업을 완료하면 다른 모든 사람 화면에 1~2초 안에 반영돼야 한다. 풀어야 할 문제는 세 가지: 서버가 클라이언트에게 어떻게 밀어줄까(WebSocket vs SSE vs 폴링), 서버가 여러 대일 때 어떻게 전부에게 퍼뜨릴까(Redis Pub/Sub), 그리고 잠깐 끊겼다 돌아온 사람이 놓친 변경을 어떻게 따라잡을까(resume cursor). 진실의 원천은 항상 DB이고, 실시간 채널은 알림일 뿐이라는 게 설계 전체를 관통하는 원칙이다.