Для проведения интервью можно использовать следующий шаблон — позволяет структурировать ответ и не забыть спросить основные моменты, необходимые для проектирования:

Скачать шаблон для https://excalidraw.com/

1. Удобство: Насколько легко начать работу и разрабатывать с использованием фреймворка.
2. Экосистема: Разнообразие и качество доступных библиотек и инструментов.
3. Сообщество: Активность и размер сообщества разработчиков.
4. Документация: Качество и полнота официальной документации.
5. Масштабируемость: Способность фреймворка справляться с ростом нагрузки и размера приложения.
6. Безопасность: Встроенные механизмы безопасности и легкость их реализации.
7. Интеграция: Простота интеграции с другими технологиями и сервисами.

При выборе фреймворка следует учитывать все эти факторы в контексте конкретного проекта. Например:

• Для быстрой разработки прототипов могут подойти Ruby on Rails или Django.
• Для высоконагруженных систем стоит обратить внимание на Actix, ASP.NET Core или Spring Boot.
• Если важна гибкость и легковесность, то Fastify или Gin могут быть хорошим выбором.
• Для корпоративных приложений с сложной бизнес-логикой Spring Boot или ASP.NET Core предоставляют широкие возможности.

Сколько серверов надо?

Согласованное хеширование (Consistent hashing) — это специальная техника хеширования в компьютерных науках, которая обладает важным свойством: при изменении размера хеш-таблицы требуется перераспределить в среднем только n/m ключей, где n — количество ключей, а m — количество слотов.

Основные особенности

• Эффективность при масштабировании: В отличие от традиционных хеш-таблиц, где изменение количества слотов приводит к перераспределению почти всех ключей, согласованное хеширование минимизирует количество перемещаемых данных.
• Распределение нагрузки: Техника равномерно распределяет ключи кэша по шардам, даже если некоторые шарды выходят из строя или становятся недоступными.

Применение

Согласованное хеширование широко используется в распределенных системах, особенно в:

• Распределенных кэшах
• Системах хранения данных (например, Amazon Dynamo)
• Сетях доставки контента (CDN)
• Балансировке нагрузки

Принцип работы

1. Ключи и серверы отображаются на виртуальную окружность (обычно от 0 до 2π).
2. Каждый ключ назначается ближайшему серверу по часовой стрелке.
3. При добавлении или удалении сервера перераспределяются только ключи, попадающие в его сегмент.

Преимущества

• Минимизация перераспределения данных при изменении количества серверов.
• Улучшение масштабируемости и отказоустойчивости распределенных систем.

Согласованное хеширование стало ключевой технологией для многих современных распределенных систем, обеспечивая эффективное распределение данных и нагрузки

Рандеву-хеширование (Rendezvous hashing) или хеширование с наибольшим случайным весом (HRW) — это алгоритм, позволяющий клиентам достичь распределенного соглашения о выборе k вариантов из n возможных. Этот метод часто применяется в распределенных системах для назначения объектов серверам или прокси.

Основные особенности

• Простота: Алгоритм концептуально прост и легок в реализации.
• Минимальное нарушение: При добавлении или удалении узла перераспределяются только объекты, связанные с этим узлом.
• Равномерное распределение: Обеспечивает равномерное распределение объектов по узлам.
• Поддержка взвешивания: Позволяет учитывать разную мощность узлов.

Принцип работы

1. Для каждого объекта и каждого узла вычисляется хеш-значение.
2. Объект назначается узлу с наибольшим хеш-значением.
3. При изменении набора узлов пересчитываются только затронутые объекты.

Применение

Рандеву-хеширование используется во многих реальных системах, включая:

• Балансировщик нагрузки GitHub
• Распределенная база данных Apache Ignite
• Файловое хранилище Tahoe-LAFS
• Pub/sub платформа Twitter EventBus

Преимущества перед согласованным хешированием

• Более простая концепция и реализация
• Не требует предварительных вычислений или хранения токенов
• Обеспечивает простое решение для распределенного k-соглашения

Рандеву-хеширование становится все более популярным в современных распределенных системах благодаря своей простоте, эффективности и гибкости

Примечания:

1. «In memory» означает, что база данных хранит данные преимущественно в оперативной памяти для быстрого доступа.
2. «Disk based» означает, что база данных в основном хранит данные на диске.
3. «Hybrid» (как в случае с Couchbase) означает, что база данных использует как память, так и диск для оптимальной производительности.
4. Значения QPS являются приблизительными и могут варьироваться в зависимости от конфигурации и нагрузки.

Перевод репозитория https://leetcode.com/discuss/career/229177/My-System-Design-Template

1. Ожидания от функционала [5 мин]

• Варианты использования
• Сценарии, которые не будут охвачены
• Кто будет использовать
• Сколько пользователей будет
• Шаблоны использования

2. Оценки [5 мин]

• Пропускная способность (QPS для запросов на чтение и запись)
• Ожидаемая латентность системы (для запросов на чтение и запись)
• Соотношение чтения/записи
• Оценки трафика
• Запись (QPS, объем данных)
• Чтение (QPS, объем данных)
• Оценки хранилища
• Оценки памяти
• Какие данные мы хотим хранить в кэше, если используем его
• Сколько RAM и машин нам нужно для достижения этого
• Объем данных для хранения на диске/SSD

3. Цели проектирования [5 мин]

• Требования к латентности и пропускной способности
• Согласованность vs Доступность [Слабая/сильная/итоговая => согласованность | Отказоустойчивость/репликация => доступность]

4. Высокоуровневый дизайн [5-10 мин]

• API для сценариев чтения/записи критических компонентов
• Схема базы данных
• Базовый алгоритм
• Высокоуровневый дизайн для сценариев чтения/записи

5. Глубокое погружение [15-20 мин]

Масштабирование алгоритма

Масштабирование отдельных компонентов:

• Доступность, согласованность и масштабируемость для каждого компонента
• Паттерны согласованности и доступности

Рассмотрение следующих компонентов, их интеграции и пользы:

a) DNS

b) CDN [Push vs Pull]

c) Балансировщики нагрузки [Активный-Пассивный, Активный-Активный, Уровень 4, Уровень 7]

d) Обратный прокси

e) Масштабирование уровня приложений [Микросервисы, Обнаружение сервисов]

f) БД [RDBMS, NoSQL]

• RDBMS
• Мастер-слейв, Мастер-мастер, Федерация, Шардинг, Денормализация, Оптимизация SQL
• NoSQL
• Ключ-Значение, Широкая колонка, Граф, Документ
• Быстрый поиск:
  • RAM [Ограниченный размер] => Redis, Memcached
  • AP [Неограниченный размер] => Cassandra, RIAK, Voldemort
  • CP [Неограниченный размер] => HBase, MongoDB, Couchbase, DynamoDB

g) Кэши

• Клиентское кэширование, CDN кэширование, Кэширование веб-сервера, Кэширование базы данных, Кэширование приложений, Кэш на уровне запросов, Кэш на уровне объектов
• Политики вытеснения:
• Cache aside
• Write through
• Write behind
• Refresh ahead

h) Асинхронность

• Очереди сообщений
• Очереди задач
• Обратное давление

i) Коммуникация

• TCP
• UDP
• REST
• RPC

6. Обоснование [5 мин]

• Пропускная способность каждого уровня
• Латентность между каждым уровнем
• Обоснование общей латентности

Времена доступа к памяти и хранилищам

• Обращение к кэшу L1: 0.5 нс
• Обращение к кэшу L2: 7 нс
• Обращение к основной памяти: 100 нс
• Чтение 1 МБ последовательно из основной памяти: 250,000 нс
• Произвольный доступ к жесткому диску: 10,000,000 нс
• Чтение 1 МБ последовательно с жесткого диска: 20,000,000 нс[3]

Эти цифры показывают, насколько критична оптимизация работы с памятью и дисками для производительности программ.

Сетевые задержки

• Пересылка 2 КБ по сети со скоростью 1 Гбит/с: 20,000 нс
• Передача сообщения туда/обратно в одном дата-центре: 500,000 нс
• Передача пакета из Калифорнии в Нидерланды и обратно: 150,000,000 нс[3]

Понимание сетевых задержек важно при разработке распределенных систем.

Другие важные числа

• Ошибка при предсказании условного перехода: 5 нс
• Открытие/закрытие мьютекса: 25 нс
• Сжатие 1 КБ быстрым алгоритмом: 3,000 нс[3]

Эти цифры помогают оценивать эффективность различных операций в коде.

Степени двойки

Разработчикам также полезно помнить степени двойки: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024[31]. Они часто встречаются при работе с памятью, файловыми системами и другими аспектами разработки.

Коды ошибок HTTP

• 403: доступ запрещен
• 404: страница не найдена
• 500: внутренняя ошибка сервера
• 503: сервис недоступен[31]

Перевод и адаптация этого репозитория https://github.com/jguamie/system-design/blob/master/notes/system-design-outline.md

Это рекомендуемый подход к решению задач проектирования систем. Не все эти темы будут актуальны для конкретной задачи.

1. Функциональные требования / Уточнения / Предположения (Functional Requirements / Clarifications / Assumptions)
2. Нефункциональные требования (Non-Functional Requirements)
   1. Согласованность vs Доступность (Consistency vs Availability)
   2. Задержка (Latency)
      1. Насколько быстрой должна быть эта система?
      2. Задержка, воспринимаемая пользователем (User-perceived latency)
      3. Задержка обработки данных (Data processing latency)
   3. Безопасность (Security)
      1. Потенциальные атаки? Как их следует смягчать?
   4. Конфиденциальность (Privacy)
      1. PII (Personally Identifiable Information — Персональные данные, позволяющие идентифицировать личность), PCI (Payment Card Industry — Индустрия платежных карт) или другие пользовательские данные
   5. Целостность данных (Data Integrity)
      1. Как восстановиться после повреждения или потери данных?
   6. Соотношение чтения:записи (Read:Write Ratio)
3. API (Application Programming Interface — Интерфейс программирования приложений)
   1. Публичные и/или внутренние API?
   2. Просты ли API для понимания?
   3. Как идентифицируются сущности?
4. Схемы хранения (Storage Schemas)
   1. SQL (Structured Query Language — Язык структурированных запросов) vs NoSQL (Not Only SQL — Не только SQL, обозначает нереляционные базы данных)
   2. Очереди сообщений (Message Queues)
5. Проектирование системы (System Design)
6. Масштабируемость (Scalability)
   1. Как масштабируется система? Учитывайте увеличение как объема данных, так и трафика.
   2. Каковы узкие места? Как их следует устранять?
   3. Каковы граничные случаи? Что может пойти не так? Предполагая, что они произойдут, как их следует решать?
   4. Как мы будем проводить стресс-тестирование этой системы?
   5. Балансировка нагрузки (Load Balancing)
   6. Автомасштабирование / Репликация (Auto-scaling / Replication)
   7. Кэширование (Caching)
   8. Партиционирование (Partitioning)
   9. Репликация (Replication)
   10. Непрерывность бизнеса и аварийное восстановление (BCDR — Business Continuity and Disaster Recovery)
   11. Интернационализация / Локализация (Internationalization / Localization)
       1. Как масштабироваться на несколько стран и языков? Не предполагайте, что в США используется только английский язык.