Copy English

Why

Simonyan's own upload of the same course opens with the reason to learn this in the AI era: when an agent writes the handlers, the person is left with the decisions the handlers cannot make, which tier owns state, which database family, which protocol, which control sits at the door. That is system design, and it is exactly the part Tech #62 calls the boundary.

A design interview and a real architecture review ask the same question in the same order: what does this component need (consistency, latency, throughput, ordering), and which of the standard choices matches that need. Skipping the question does not remove the trade-off, it just means the trade-off was made by accident — a database picked because it was already running, a load-balancing algorithm left at its default, a security control added only after an incident. Naming the choice explicitly is what turns an implementation detail into something the Auditor, or an interviewer, can check.

How it works

Data tier: pick by access pattern, not habit

A single server outgrows itself when the web tier and the data tier compete for the same CPU and memory; the first split is always web tier from data tier (03:33, 07:16). After that the database choice follows the access pattern, not preference.

Scaling and load balancing: seven algorithms behind one idea

Scaling up (bigger hardware) is fast but hits a ceiling and stays a single point of failure; scaling out (more instances behind a load balancer) is the only path at real load (13:46, 14:07, 14:34). The course names seven load-balancing algorithms (17:49): round robin, least connections, least response time, IP hash, weighted, geographical, and consistent hashing. The first six route each new request by a rule; consistent hashing is different — it maps both nodes and keys onto a hash ring so that adding or removing a node only remaps the keys next to it, which is why it is the standard choice for cache and shard placement rather than plain request routing (23:12, 23:59). SPOF is handled separately from the algorithm: health checks pull a failing instance out of rotation automatically, the load balancer itself is run active-passive or active-active so it is not the new single point of failure, and unhealthy instances are replaced rather than nursed (24:27, 27:05, 29:17, 30:20).

API style and wire protocol: match the shape of the call

REST names resources as plural nouns, uses HTTP verbs for the operation, filters and paginates through query parameters, and caches at the HTTP layer (33:48, 01:07:05, 01:09:40, 01:17:47). GraphQL exists because Facebook's REST clients needed several round trips and still got the wrong shape of data — over- or under-fetching — so GraphQL exposes one endpoint where the client states exactly which fields it wants (Query, Mutation); the cost is that errors come back inside a 200 response as an errors array, so query-depth limits are not optional (34:26, 37:49, 01:19:44, 01:21:08, 01:23:26, 01:24:27). gRPC serializes with Protocol Buffers over HTTP/2, supports bidirectional streaming, and skips JSON parsing — which is why it is the default for internal microservice calls rather than public APIs (35:50, 36:11, 56:10, 56:35).

Underneath the API style sits the transport. TCP's handshake, ordering guarantee and retransmission make it the only acceptable choice for payments, banking and auth (59:29, 01:02:38, 01:03:57); UDP skips both and is used where a late packet is worse than a lost one — streaming, calls, games (01:01:24, 01:02:18, 01:04:00). WebSocket sits on top of TCP for real-time bidirectional push, replacing polling (52:08, 53:27); AMQP is for asynchronous queues and brokers (54:50).

Authentication vs authorization: two different questions

Authentication answers "who is this" (01:26:33); authorization answers "what can they do" (01:46:14), and the course treats these as separate systems, not one. Session-based auth keeps state on the server or in Redis and hands the client a session cookie — simple, but stateful, which constrains horizontal scaling (01:33:18, 01:34:40). JWTs are signed claims: the server verifies a signature instead of querying a database, which is what makes them stateless; a short-lived access token (15 minutes to an hour) pairs with a longer-lived refresh token kept in an HTTP-only cookie to block XSS theft (01:35:46, 01:37:57, 01:38:42). OIDC adds an ID token on top of OAuth 2.0 for social login and SSO (01:41:10, 01:43:11). For authorization the course names three models — RBAC (roles map to permission sets), ABAC (rules over attributes), and ACL (per-resource, per-user, the Google Drive model) — and is careful to state that OAuth 2.0 itself is not authentication: it is an authorization framework for delegating a limited, revocable token to a third party without handing over a password (01:39:30, 01:49:22, 01:52:49, 01:53:39).

Seven-item production security checklist

The course closes with seven controls it treats as non-negotiable before a production API ships (01:57:27–02:04:05): rate limiting per endpoint, per user/IP, and globally; CORS; SQL/NoSQL injection defense via parameterized queries or an ORM; a WAF; a VPN or private network for admin dashboards and backend-only APIs; CSRF tokens; and XSS defense via input sanitization.

Where it lands in Jayverse

• Verex: the five tables above are the architecture review. Every row is a checkable claim about Verex's stack — Postgres for orders, REST today, TCP for the API, JWT plus wallet signature for auth — and every blank cell (Redis, CSRF, XSS) is a named follow-up rather than an unknown unknown.
• Rabbit: the 7715 mandate is the OAuth 2.0 analogy, exactly. A session-key mandate hands a delegate a limited, revocable capability without sharing a key — that is what OAuth 2.0's grant-a-token-not-a-password model is for. The portal's session-vs-JWT question (stateful cookie vs stateless signature) is the same trade-off the course lays out for scaling.
• Devnet: rate limiting and health checks belong on Anvil, not just the API. The course's SPOF section (health checks pull a bad instance out of rotation) applies to the hosted Anvil RPC the same way it applies to a web server.
• Auditor: every "Jayverse today" cell is a checkable rule, including the blank ones. "Unknown — needs a check" for Redis, CSRF and XSS is itself the correct Auditor entry: a stated gap, not a silent one.
• Eng and Theory: this is the interview syllabus, and consistent hashing is a Theory item. The 40-minute system-design interview question runs in roughly this order — data tier, scaling, API, auth, security — so this file doubles as interview prep; consistent hashing's hash-ring remapping belongs with the queueing and scheduling entries in Theory.

Verified and unverified

Verified on 2026-09-19: freeCodeCamp.org publishes long-form system-design courses on YouTube, and every concept named above is textbook material with documented behavior — ACID on RDBMS, the five database-family split, the seven standard load-balancing algorithms including consistent hashing's hash-ring remapping, REST/GraphQL/gRPC as described (GraphQL's errors-array-inside-200 behavior is a well-known footgun; gRPC's Protocol Buffers over HTTP/2 is accurate), TCP's handshake and reliability guarantees versus UDP's connectionless model, JWT as stateless signature verification, OIDC as an OAuth 2.0 extension, RBAC/ABAC/ACL as standard authorization models, and OAuth 2.0 as an authorization (not authentication) framework. Taken from the summary and not independently checked: the exact timestamps, and the video's runtime beyond "about two hours."

Sources: YouTube — freeCodeCamp.org, "System Design Course – APIs, Databases, Caching, CDNs, Load Balancing & Production Infra" · YouTube — Hayk Simonyan, original course upload (same curriculum; adds the framing that system design matters more, not less, when agents write the code, because the human is left with the boundaries) · related items: Tech #96 (Homa: TCP vs message transport), Tech #101 (ADK voice: open streams), Tech #62 (agentic engineering writes the boundaries), the faucet item a-faucet-is-a-payout, Dark Horse (b) security-hole research.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

시스템 설계 강의 — 서버 한 대에서 모든 설계 인터뷰가 시험하는 일곱 가지 결정까지, 두 시간의 여정

freeCodeCamp.org가 두 시간짜리 강의 "System Design Course – APIs, Databases, Caching, CDNs, Load Balancing & Production Infra"(YouTube, C842vFY5kRo)를 공개했다. 가장 작은 시스템 — 웹 앱, 데이터베이스, 캐시가 서버 한 대에서 함께 돌아가는 상태 — 에서 시작해 표준 경로를 따라간다. 웹 티어와 데이터 티어를 분리하고, 접근 패턴에 따라 데이터베이스 계열을 고르고, 로드 밸런서 뒤에서 웹 티어를 수평으로 확장하고, API 스타일과 전송 프로토콜을 고르고, 인증과 인가를 분리하고, 프로덕션 API가 노출되기 전 필요한 통제 목록으로 마무리한다. 강의는 정의보다 트레이드오프에 실제 시간을 쓴다. 데이터베이스 5계열, 로드 밸런싱 알고리즘 7종, API 스타일 3종, 전송 프로토콜 2종, 인증 방식 2종, 보안 항목 7개.

Jayverse에서 이것은 새로운 정보가 아니라 체크리스트다. 아래 모든 선택은 이미 Verex, Rabbit, Number 어딘가에 내려져 있다. 강의의 가치는 "우리는 그렇게 했다"를 행마다 명시된 규칙과 대조할 수 있는 표로 바꾸는 데 있다.

왜

같은 강의의 Simonyan 원본 업로드는 AI 시대에 이것을 배워야 하는 이유로 시작한다. 에이전트가 핸들러를 쓰면 사람에게는 핸들러가 내릴 수 없는 결정이 남는다. 어느 티어가 상태를 소유하는가, 어느 데이터베이스 계열인가, 어느 프로토콜인가, 어느 통제가 문 앞에 서는가. 그것이 시스템 설계이고, Tech #62가 경계라 부르는 바로 그 부분이다.

설계 인터뷰와 실제 아키텍처 리뷰는 같은 순서로 같은 질문을 한다. 이 컴포넌트에 무엇이 필요한가(일관성, 지연, 처리량, 순서 보장), 그리고 표준 선택지 중 어느 것이 그 필요에 맞는가. 질문을 건너뛴다고 트레이드오프가 사라지지 않는다. 그저 트레이드오프가 우연히 정해졌다는 뜻일 뿐이다 — 이미 돌고 있어서 고른 데이터베이스, 기본값에 그대로 둔 로드 밸런싱 알고리즘, 사고가 난 뒤에야 추가한 보안 통제. 선택을 명시적으로 이름 붙이는 것이 구현 디테일을 Auditor나 인터뷰어가 확인할 수 있는 것으로 바꾼다.

동작 방식

데이터 티어: 습관이 아니라 접근 패턴으로 고른다

서버 한 대는 웹 티어와 데이터 티어가 같은 CPU와 메모리를 두고 경쟁할 때 한계를 드러낸다. 첫 분리는 언제나 웹 티어와 데이터 티어의 분리다(03:33, 07:16). 그다음 데이터베이스 선택은 선호가 아니라 접근 패턴을 따른다.

스케일링과 로드 밸런싱: 한 아이디어 뒤의 일곱 알고리즘

스케일업(더 큰 하드웨어)은 빠르지만 한계와 단일 장애점(SPOF)을 남긴다. 스케일아웃(로드 밸런서 뒤에 인스턴스를 더 두는 것)이 실제 트래픽에서 유일한 길이다(13:46, 14:07, 14:34). 강의는 로드 밸런싱 알고리즘 일곱 개를 꼽는다(17:49). round robin, least connections, least response time, IP hash, weighted, geographical, consistent hashing. 앞의 여섯은 규칙 하나로 매 요청을 보낸다. consistent hashing은 다르다. 노드와 키를 모두 해시 링 위에 올려서, 노드를 추가하거나 제거해도 그 옆의 키만 재매핑되게 한다. 그래서 단순 요청 라우팅이 아니라 캐시·샤드 배치의 표준 선택이 된다(23:12, 23:59). SPOF는 알고리즘과 별도로 다룬다. 헬스 체크가 실패한 인스턴스를 자동으로 로테이션에서 빼고, 로드 밸런서 자체는 active-passive나 active-active로 이중화해 새로운 단일 장애점이 되지 않게 하며, 고장난 인스턴스는 고치는 대신 교체한다(24:27, 27:05, 29:17, 30:20).

API 스타일과 전송 프로토콜: 호출의 모양에 맞춘다

REST는 리소스를 복수형 명사로 이름 붙이고, 동작은 HTTP 동사로, 필터와 페이지네이션은 쿼리 파라미터로, 캐싱은 HTTP 계층에서 한다(33:48, 01:07:05, 01:09:40, 01:17:47). GraphQL은 페이스북의 REST 클라이언트가 여러 번 왕복하고도 잘못된 모양의 데이터를 받았기 때문에 — 오버페칭이거나 언더페칭 — 나왔다. 그래서 GraphQL은 단일 엔드포인트에서 클라이언트가 정확히 어떤 필드를 원하는지 명시한다(Query, Mutation). 대가는 에러가 200 응답 안에 errors 배열로 돌아온다는 것이라, 쿼리 깊이 제한이 선택이 아니다(34:26, 37:49, 01:19:44, 01:21:08, 01:23:26, 01:24:27). gRPC는 Protocol Buffers로 HTTP/2 위에서 직렬화하고, 양방향 스트리밍을 지원하며, JSON 파싱을 건너뛴다 — 그래서 공개 API가 아니라 내부 마이크로서비스 간 호출의 기본값이다(35:50, 36:11, 56:10, 56:35).

API 스타일 아래에는 전송 계층 선택이 있다. TCP의 핸드셰이크, 순서 보장, 재전송은 결제·뱅킹·인증에 유일하게 허용되는 선택으로 만든다(59:29, 01:02:38, 01:03:57). UDP는 둘 다 건너뛰고, 유실보다 지연이 더 나쁜 곳 — 스트리밍, 화상통화, 실시간 게임 — 에 쓰인다(01:01:24, 01:02:18, 01:04:00). WebSocket은 TCP 위에서 실시간 양방향 푸시를 하며 폴링을 대체한다(52:08, 53:27). AMQP는 비동기 큐·브로커용이다(54:50).

인증 대 인가: 서로 다른 두 질문

인증은 "누구인가"에 답하고(01:26:33), 인가는 "무엇을 할 수 있는가"에 답한다(01:46:14). 강의는 이 둘을 하나가 아니라 별개의 시스템으로 다룬다. 세션 기반 인증은 서버나 Redis에 상태를 두고 클라이언트에 세션 쿠키를 준다 — 단순하지만 stateful이라 수평 확장을 제약한다(01:33:18, 01:34:40). JWT는 서명된 클레임이다. 서버는 DB를 조회하는 대신 서명을 검증하는데, 이것이 JWT를 stateless로 만드는 이유다. 짧은 수명(15분~1시간)의 access 토큰이 HTTP-only 쿠키에 담긴 더 긴 수명의 refresh 토큰과 짝을 이뤄 XSS 탈취를 막는다(01:35:46, 01:37:57, 01:38:42). OIDC는 OAuth 2.0 위에 ID 토큰을 얹어 소셜 로그인과 SSO를 지원한다(01:41:10, 01:43:11). 인가에 대해 강의는 세 모델을 꼽는다 — RBAC(역할이 권한 집합에 매핑), ABAC(속성에 대한 규칙), ACL(리소스별·사용자별, Google Drive 모델) — 그리고 OAuth 2.0 자체는 인증 도구가 아니라고 명확히 한다. 비밀번호를 넘기지 않고 제한적이고 철회 가능한 토큰을 제3자에게 위임하는 인가 프레임워크다(01:39:30, 01:49:22, 01:52:49, 01:53:39).

프로덕션 보안 7항목 체크리스트

강의는 프로덕션 API가 노출되기 전 타협 불가로 다루는 통제 일곱 가지로 마무리한다(01:57:27–02:04:05). 엔드포인트별·유저/IP별·전역 rate limiting; CORS; 파라미터화 쿼리나 ORM을 통한 SQL/NoSQL injection 방어; WAF; 관리자 대시보드와 백엔드 전용 API를 위한 VPN 또는 사설망; CSRF 토큰; 입력 sanitize를 통한 XSS 방어.

Jayverse에서의 위치

• Verex: 위 다섯 표가 곧 아키텍처 리뷰다. 모든 행이 Verex 스택에 대한 검증 가능한 주장이다 — 주문에 Postgres, 현재 REST, API에 TCP, 인증에 JWT와 지갑 서명 — 그리고 빈 칸(Redis, CSRF, XSS)은 알 수 없는 미지가 아니라 이름 붙은 후속 작업이다.
• Rabbit: 7715 mandate가 정확히 OAuth 2.0의 유비다. 세션키 mandate는 키를 공유하지 않고 델리게이트에게 제한적이고 철회 가능한 능력을 준다 — 이것이 OAuth 2.0의 "비밀번호가 아니라 토큰을 준다" 모델이 하는 일이다. 포털의 세션 대 JWT 질문(상태 있는 쿠키 대 무상태 서명)은 강의가 스케일링에서 설명하는 것과 같은 트레이드오프다.
• Devnet: rate limiting과 헬스 체크는 API뿐 아니라 Anvil에도 있어야 한다. 강의의 SPOF 절(헬스 체크가 고장난 인스턴스를 로테이션에서 뺀다)은 호스팅된 Anvil RPC에도 웹 서버와 똑같이 적용된다.
• Auditor: "Jayverse 현재" 칸은 빈 칸까지 포함해 모두 검증 가능한 규칙이다. Redis, CSRF, XSS에 대한 "미확인 — 점검 필요"는 그 자체로 올바른 Auditor 항목이다. 조용한 공백이 아니라 명시된 공백.
• Eng와 Theory: 이것이 인터뷰 커리큘럼이고, consistent hashing은 Theory 항목이다. 40분짜리 시스템 설계 인터뷰 문제는 대략 이 순서로 진행된다 — 데이터 티어, 스케일링, API, 인증, 보안 — 그래서 이 파일은 인터뷰 준비를 겸한다. consistent hashing의 해시 링 재매핑은 Theory의 큐잉·스케줄링 항목과 함께 놓인다.

확인된 것과 미확인

2026-09-19 확인: freeCodeCamp.org는 YouTube에 장편 시스템 설계 강의를 공개하는 채널이고, 위에서 이름 붙인 개념은 모두 문서화된 동작을 가진 교과서적 시스템 설계 내용이다 — RDBMS의 ACID, 데이터베이스 5계열 구분, consistent hashing의 해시 링 재매핑을 포함한 표준 로드 밸런싱 알고리즘 7종, 설명된 그대로의 REST/GraphQL/gRPC(GraphQL의 "errors 배열이 200 안에" 동작은 잘 알려진 함정이고, gRPC의 Protocol Buffers-over-HTTP/2도 정확하다), TCP의 핸드셰이크와 신뢰성 보장 대 UDP의 비연결 모델, 무상태 서명 검증으로서의 JWT, OAuth 2.0 확장으로서의 OIDC, 표준 인가 모델로서의 RBAC/ABAC/ACL, 인증이 아니라 인가 프레임워크로서의 OAuth 2.0. 요약에서 가져왔고 독립 확인하지 않은 것: 정확한 타임스탬프, "약 두 시간" 이상의 영상 러닝타임.

출처: YouTube — freeCodeCamp.org, "System Design Course – APIs, Databases, Caching, CDNs, Load Balancing & Production Infra" · YouTube — Hayk Simonyan 원본 업로드 (같은 커리큘럼. 에이전트가 코드를 쓰는 시대에 시스템 설계가 덜 아니라 더 중요해진다는 프레이밍을 더한다. 사람에게 남는 것이 경계이기 때문이다) · 관련 항목: Tech #96(Homa: TCP 대 메시지 전송), Tech #101(ADK voice: 오픈 스트림), Tech #62(에이전틱 엔지니어링은 경계를 쓴다), faucet 항목 a-faucet-is-a-payout, Dark Horse (b) 보안 취약점 연구.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑