Системный дизайн для Go-разработчика¶

Этот раздел — твой учебник по системному дизайну. Не справочник «прочёл и забыл», а конструктор: сначала фундамент, потом блоки (БД, кэш, очереди), потом сборка готовых архитектур, в конце — как это всё рассказывать на собеседовании.

Если ты уже сильный middle, можешь сразу прыгать в case-studies и interview-playbook. Если ты junior — иди по порядку.

Зачем тебе системный дизайн¶

System design — это умение собрать сервис, который выживет под нагрузкой, не упадёт от падения соседа и не сожжёт счёт за облако. На собеседованиях это половина успеха для middle+ позиции: код спросят на 30 минут, а архитектуру — на час, и именно она определит уровень и оффер.

🧩 Простыми словами. Представь, что тебе принесли заказ: «сделай Twitter». Junior пишет CRUD за неделю. Middle думает 20 минут, рисует схему с кэшем и очередью, потом пишет. Senior сначала спрашивает: «А сколько RPS? А география? А сколько данных? А деньги на инфру есть?» — и только потом рисует. Этот раздел учит думать как третий.

Карта раздела¶

#	Страница	О чём
1	Основы и подход к задаче	4 шага собеса: requirements → API → data → scale
2	Масштабирование	Vertical/horizontal, sharding, partitioning, federation
3	Консистентность и CAP	Strong/eventual, CAP, PACELC, реальные системы
4	Кеширование	Cache-aside, write-through, TTL, invalidation, hot keys
5	Базы данных	SQL vs NoSQL, репликация, индексы, query patterns
6	Балансировка нагрузки	L4/L7, алгоритмы, sticky, health checks, geo-LB
7	Очереди и стримы	Kafka/Rabbit/NATS, ordering, exactly-once, outbox
8	Микросервисы	Когда пилить, API gateway, saga, CQRS, service mesh
9	Отказоустойчивость	Timeouts, retry, circuit breaker, idempotency
10	Observability	RED/USE, трейсы, SLI/SLO, error budget
11	Case studies	TinyURL, Twitter feed, чат, Uber, web crawler
12	Interview playbook	Тайминг, шаги, вопросы по уровням, чек-лист

Три уровня глубины¶

Каждая тема имеет три уровня — junior (L1), middle (L2), senior (L3). Этот блок помогает тебе калибровать ответ на собесе и не утонуть в деталях, к которым тебя ещё не готовы спрашивать.

📊 L1 (junior) — знаешь термин, можешь объяснить на пальцах, привести один учебный пример. Уровень: «понимаю, что такое cache-aside, видел в проекте».

📊 L2 (middle) — умеешь применить, знаешь когда что выбирать, понимаешь trade-offs. Уровень: «выбрал Redis vs Memcached потому что нужен TTL и persistence; настроил maxmemory-policy=allkeys-lru».

📊 L3 (senior) — проектируешь сам, знаешь edge-кейсы, помнишь incident'ы. Уровень: «инвалидация кэша через pub/sub когда ушли из read-replica к eventual-consistent NoSQL — было два инцидента, исправили через выбор ключа = hash(user_id) + version».

Как пользоваться разделом¶

Читай по порядку, если новичок. Каждая страница ссылается на следующую.
Не зубри определения. Главное — понять, как это работает в проде, и какие проблемы решает. Зубрёжкой собес не пройти, а живой опыт — да.
Делай мини-задачи в конце каждой страницы. Они подсвечивают те самые trade-offs, которые любят спрашивать.
Задавай вопросы AI-ментору. В каждой странице есть блок «🤖 Что спрашивает AI-ментор» — это типовые вопросы, на которые материал даёт ответ. Идеально для самопроверки.
Возвращайся. Раздел — справочник. Перед собесом перечитай interview-playbook и нужные case studies.

Что ты будешь уметь после раздела¶

graph TD
    Start[Сейчас:<br/>знаю Go, написал API + DB] --> F[Фундамент:<br/>требования → API → data → scale]
    F --> B[Блоки:<br/>cache, queue, LB, replication]
    B --> P[Паттерны:<br/>circuit breaker, saga, outbox]
    B --> O[Observability:<br/>metrics, logs, traces]
    P --> Cases[Готовые архитектуры:<br/>TinyURL, Feed, Chat, Uber]
    O --> Cases
    Cases --> Goal[Можешь:<br/>пройти system design на middle/senior<br/>+ спроектировать сервис в работе]
    style Start fill:#fee,stroke:#900
    style Goal fill:#efe,stroke:#090

После раздела ты:

Спроектируешь URL shortener, news feed, чат, ride-sharing с RPS / latency / capacity estimation.
Объяснишь, почему выбрал Postgres + Redis + Kafka именно так, и что было бы при замене на Mongo / Memcached / RabbitMQ.
Расскажешь про CAP, PACELC, exactly-once на примерах из жизни (Dynamo, Spanner, Kafka EOS) — без зубрёжки.
Не упустишь на собесе: шардирование, репликация, кэш, очередь, идемпотентность, таймауты, метрики. Это «не забыть» — главный фактор успеха.

Где смотреть глубже¶

📖 DDIA (Designing Data-Intensive Applications, Kleppmann) — библия системного дизайна. Каждая глава — отдельный мир.
📖 System Design Interview Alex Xu, vol 1 + 2 — рабочий учебник под собес.
📖 Microservices.io Chris Richardson — каталог паттернов.
📖 System Design Primer (donnemartin/system-design-primer) — открытый источник, мы тут на нём опираемся, но переписали под Go-контекст.
📰 Papers we love: Dynamo, Spanner, Kafka, Raft, MapReduce. Senior-уровень.

📝 Подумай¶

Если на собесе тебя спрашивают «спроектируй Twitter», какой первый вопрос ты задашь интервьюеру?
Чем отличается ответ на этот же вопрос для junior, middle и senior?
Назови три компонента архитектуры, которые есть почти в любом веб-сервисе.

Ответ

«Сколько пользователей и какой RPS?» — без этого нельзя выбрать ни БД, ни схему. Дальше: «read-heavy или write-heavy?», «географическое распределение?», «какой acceptable latency?». Только после этого — рисовать.
Junior — нарисует CRUD с одной БД. Middle — добавит cache + read replicas + очередь + рассуждение про шардирование. Senior — начнёт с capacity estimation (DAU × tweets/user × bytes), обсудит fan-out on write vs fan-in on read, упомянет hot users (Justin Bieber problem), и предложит trade-off.
Load balancer + application + database. Дальше обычно идут cache (Redis) и очередь (Kafka), но эти три — фундамент.

Готов? Начни с fundamentals.md — там четыре шага собеседования.