Skip to content

system-design.md

Latest commit

 

History

History
159 lines (120 loc) · 7.53 KB

system-design.md

File metadata and controls

159 lines (120 loc) · 7.53 KB
Raw

System Design

Архитектурное «мясо»: то, чем оперируешь, когда рисуешь систему на доске, плюс как проходить саму сисдиз-секцию (тайминг, C4, фрейм ответа) — см. в конце.

Нефункциональные требования (NFR)

  • latency / throughput
  • SLA / SLO / availability
  • scalability (вертикальная vs горизонтальная)
  • consistency vs availability (CAP)
  • cost awareness
  • security & compliance

API & контракты

  • REST vs GraphQL vs gRPC
  • версионирование API
  • идемпотентность
  • пагинация (offset vs cursor)
  • rate limiting / throttling
  • backward compatibility

Кэширование

  • где кэшировать: CDN / reverse proxy / app / DB
  • write-through / write-back / cache-aside
  • инвалидация кэша
  • Redis vs Memcached

Асинхронщина и фоновые задачи

  • когда синхрон, когда async
  • очереди vs event streaming
  • exactly-once / at-least-once
  • дедупликация задач
  • идемпотентные воркеры

Надёжность и отказоустойчивость

  • retries с backoff + jitter
  • circuit breaker
  • timeouts
  • graceful degradation
  • bulkheads

Observability

  • structured logs
  • метрики (RED / USE)
  • трассировка
  • алерты: когда и на что

Миграции и эволюция системы

  • zero-downtime migrations
  • feature flags
  • blue/green vs canary
  • как менять схему БД без даунтайма

Архитектурные подходы (DDD + event-driven)

  1. Когда DDD — оверхед?
  2. Как bounded context ложится на микросервисы?
  3. Что делать, если бизнес-логика простая?
  4. Repository на примере abstraction над storage: почему не дергать ORM напрямую?
  5. Entity vs Value Object
  6. Event vs Command: CreateOrder (command) vs OrderCreated (event)
  7. PubSub: producer не знает consumer + слабая связность системы
  8. Eventual Consistency: данные сходятся "не сразу" + между сервисами нет транзакций. Пример: пользователь создал заказ, но не видит его сразу — почему?
  9. Outbox Pattern

Ссылочки, пока работают

Базы данных

  • OLTP vs OLAP
  • read-heavy vs write-heavy
  • когда индексы вредят
  • composite indexes
  • hot keys
  • реплика лаг и его последствия
  • шардинг: по чему и какие проблемы

Очереди

Главное — модель мышления, а не список отличий.

  • queue vs log
  • ordering
  • retention
  • replay
  • consumer groups
  • exactly-once (почему почти никогда нет)
  1. «У тебя события оплаты и уведомления. Какую очередь выберешь и почему?»

Kubernetes

  • зачем вообще k8s
  • pod vs deployment vs statefulset
  • config & secrets
  • liveness / readiness
  • scaling стратегии
  • как сервисы находят друг друга
  1. Почему нельзя просто увеличить replicas и всё станет хорошо?

Облака

  • managed vs self-hosted
  • vendor lock-in
  • стоимость
  • сети (VPC, private/public)
  • IAM и безопасность
  1. Что ты возьмёшь managed, а что оставишь самописным — и почему?

Процесс сисдиз-интервью

Общие рекомендации

  • нужно брать инициативу на себя и вести процесс проектирования решения (буквально показать что ты "ведущий" разработчик)
  • проговаривать и фиксировать все нюансы стикерами на схеме
  • c4 model знать как устроена и применять на интервью. Нам понадобятся первые два уровня + список требований
  • подготовить миро доску заранее с частыми компонентами и научиться с ней работать, чтобы не тупить на интервью
  • следить за таймингом самому (10 минут сбор требований, 15 минут С1, 25 минут С2, 10 минут запаса на обсудить что забыли и не учли)
  • общая архитектура приложения важнее детальных апишек/контроллеров
  • строить речь коротко и чётко по делу, смысла растягивать интервью тут мало - наша задача за час нарисовать на "салфетке" цельную систему и доказать что это будет решать наши задачи и масштабироваться при росте нагрузки
  • весь фокус на критическом пути юзера. Всё что стороннее рисуем сбоку на схеме и проговариваем, что это не рассматриваем сегодня
  • дискретные ответы не наш путь: не "берём PG как бд", а "исходя из типа нагрузки и объёма данных берём sql совместимую БД и предусматриваем несколько реплик на чтение"
  • строить сверху вглубь, никаких конкретных технологий на первом уровне диаграмм
  • не забыть оценку нагрузки и подсвечиваем бутылочные горлышки стикерами на схеме
  • рисуем как мы эти горлышки будем расшивать масштабируясь
  • нужно выбрать стек правильно (от наших требований к пропускной способности)
  • нужно выбрать базу правильно (от наших требований и интенсивности записи-чтения)
  • нужно не забыть про кеш (и как мы его инвалидируем!)
  • нужно не забыть про масштабирование и разделение всего и вся в этом контексте

Бонусные секции, если осталось время

  • оценить стоимость поддержки (в том числе найма)
  • оценить стоимость железа на всё про всё и подсветить как будет расти при масштабировании

Универсальный фрейм для любого вопроса

  • Уточнение контекста
  • нагрузка
  • тип данных
  • SLA
  • команда / сроки
  1. Простое базовое решение
  2. Проблемы базового решения
  3. Улучшения по мере роста
  4. Трейдофы