system-design-primer/README-ru.md

English | 日本語 | Русский | 简体中文 | 繁體中文

Пособие по Проектированию Cистем

Contributing: Russian translation

WARNING: the document is currently being translated.

Thank you for your interest in contributing to Russian translation! If you want to contribute, please do the following:

• choose a task for a section which you want to translate in the Project
• assign it to yourself and move it to In progress
• text in comments is copied from original and is kept in sync. you can use it as a source for translation, but do not change it
• make PR to this fork. When translation is complete, all changes will go into one PR to main repository
• do not change Header names and internal links, keep them original. To avoid broken links, they all will be updated after document is completely translated before final PR to main repository

Мотивация

Узнайте, как проектировать крупномасштабные системы.

Подготовьтесь к собеседованию по проектированию системы.

Научитесь проектировать крупномасштабные системы

Умение проектировать масштабируемые системы поможет вам стать лучшим инженером.

Проектирование систем - это широкая тема. В сети есть огромное количество ресурсов по принципам проектирования систем.

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

Учитесь у сообщества по разработке ПО с открытым исходным кодом

Это постоянно обновляемый проект с открытым исходным кодом.

Contributions очень приветствуются!

Подготовка к собеседованию по проектированию системы

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

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

Дополнительные темы для подготовки к собеседованию:

• Study guide
• How to approach a system design interview question
• System design interview questions, with solutions
• Object-oriented design interview questions, with solutions
• Additional system design interview questions

Anki flashcards

Предоставленные карточки Anki могут быть использованы для повторения и запоминания ключевых концепций проектирования систем.

• System design deck
• System design exercises deck
• Object oriented design exercises deck

Отлично подходят для использования на ходу.

Coding Resource: Interactive Coding Challenges

Ищете ресурсы для подготовки к Coding Interview?

Посмотрите другой репозиторий Interactive Coding Challenges, который тоже содержит колоду карт Anki:

• Coding deck

Contributing

Учитесь у сообщества.

Не стесняйтесь отправлять запросы на:

• Исправление ошибок
• Улучшение разделов
• Добавление новых разделов
• Перевод

Контент, который нуждается в некоторой полировке, помещается в раздел В разработке.

Ознакомьтесь с Принципами Содействия.

Index of system design topics

Обобщение различных тем по проектирования систем, включая преимущества и недостатки. Любое решение требует компромисса.

Каждый раздел содержит ссылки на более подробное описание.

• System design topics: start here
  • Step 1: Review the scalability video lecture
  • Step 2: Review the scalability article
  • Next steps
• Performance vs scalability
• Latency vs throughput
• Availability vs consistency
  • CAP theorem
    • CP - consistency and partition tolerance
    • AP - availability and partition tolerance
• Consistency patterns
  • Weak consistency
  • Eventual consistency
  • Strong consistency
• Availability patterns
  • Fail-over
  • Replication
  • Availability in numbers
• Domain name system
• Content delivery network
  • Push CDNs
  • Pull CDNs
• Load balancer
  • Active-passive
  • Active-active
  • Layer 4 load balancing
  • Layer 7 load balancing
  • Horizontal scaling
• Reverse proxy (web server)
  • Load balancer vs reverse proxy
• Application layer
  • Microservices
  • Service discovery
• Database
  • Relational database management system (RDBMS)
    • Master-slave replication
    • Master-master replication
    • Federation
    • Sharding
    • Denormalization
    • SQL tuning
  • NoSQL
    • Key-value store
    • Document store
    • Wide column store
    • Graph Database
  • SQL or NoSQL
• Cache
  • Client caching
  • CDN caching
  • Web server caching
  • Database caching
  • Application caching
  • Caching at the database query level
  • Caching at the object level
  • When to update the cache
    • Cache-aside
    • Write-through
    • Write-behind (write-back)
    • Refresh-ahead
• Asynchronism
  • Message queues
  • Task queues
  • Back pressure
• Communication
  • Hypertext transfer protocol (HTTP)
  • Transmission control protocol (TCP)
  • User datagram protocol (UDP)
  • Remote procedure call (RPC)
  • Representational state transfer (REST)
• Security
• Appendix
  • Powers of two table
  • Latency numbers every programmer should know
  • Additional system design interview questions
  • Real world architectures
  • Company architectures
  • Company engineering blogs
• Under development
• Credits
• Contact info
• License

Study guide

Предлагаемые темы для повторения в зависимости от того, сколько у вас есть времени для подготовки к интервью (мало, средне, много)

Вопрос: Надо ли мне знать все из этого документа для интервью?

Ответ: Нет, не обязательно.

То, что вас будут спрашивать на интервью, зависит от:

• Вашего опыта - сколько времени и чем вы занимались
• Должности, на которую вы собеседуетесь
• Компания, в которую вы собеседуетесь
• Удача

Ожидается, что более опытные кандидаты в общем случае знают больше о проектировании систем, а архитекторы и руководители комманд знают больше, чем индивидуальные разработчики. Топовые IT компании скорее всего будут проводить один или более этапов собеседования по проектированию систем.

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

• Короткий срок - настраиватесь на широту покрытия тем. Тренируйтесь отвечать на некоторые вопросы.
• Средний срок - настраиватесь на широту и немного глубины покрытия тем. Тренируйтесь отвечать на многие вопросы.
• Длительный срок - настраиватесь на широту и больше глубины покрытия тем. Тренируйтесь отвечать на большинство вопросов.

	Малый срок	Средний срок	Длительный срок
Читайте System design topics, чтобы получить общее понимание, как работают системы	👍	👍	👍
Почитайте несколько статей из блогов компаний, в который вы собеседуетесь Company engineering blogs	👍	👍	👍
Посмотрите несколько Real world architectures	👍	👍	👍
How to approach a system design interview question	👍	👍	👍
System design interview questions with solutions	Немного	Много	Большинство
Object-oriented design interview questions with solutions	Немного	Много	Большинство
Additional system design interview questions	Немного	Много	Большинство

How to approach a system design interview question

Как отвечать на вопросы на интерьвю по проектированию систем

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

Изучите раздел System design interview questions with solutions и используйте шаги, описанные ниже.

Step 1: Outline use cases, constraints, and assumptions

Соберите требование и оцените рамки задачи. Задавайте вопросы, чтобы уточнить варианты использования и ограничения. Обсудите допущения.

• Кто будет использовать решение?
• Как его будут использовать?
• Сколько пользователей?
• Что система должна делать?
• Что система получает на вход, и что должно быть на выходе?
• Какое количество данных система должна обрабатывать?
• Сколько ожидается запросов в секунду?
• Какое соотношение количества операций на чтение и запись?

Step 2: Create a high level design

Сделайте набросок проекта с наиболее важными компонентами:

• Выделите главные компоненты и связи между ними
• Обоснуйте ваши идеи

Step 3: Design core components

Детализируйте каждый компонент. Например, если вас попросили разработать design a url shortening service, обсудите следующие моменты:

• Генерация и хранения хэша оригинального URL
  • MD5 и Base62
  • Коллизии хэш-функции
  • SQL или NoSQL
  • Схема базы данных
• Перевод хэшированного URL в оригинальный URL
  • Поиск в базе данных
• API и объектно-ориентированное проектирование

Step 4: Scale the design

Определите узкие места и разберитесь с ними, учитывая данные ограничения. Например, для решение проблем с масштабируемостью, может ли вам понадобиться что-то из:

• Балансировщик нагрузки
• Горизонтальное машстабирование
• Кэширование
• Шардинг (sharding) базы данных

Обсудите потенциальные варианты и компромиссы. Разберитесь с узкими местами используя principles of scalable system design.

Back-of-the-envelope calculations

Вас могу спросить сделать оценку решения по некоторые параметрам. Некоторые разделы Appendix могут с этим помочь:

• Use back of the envelope calculations
• Powers of two table
• Latency numbers every programmer should know

Source(s) and further reading

Посмотрите следующие ссылки, чтобы понять, что можно ожидать (внешние ссылки без перевода):

• Use back of the envelope calculations
• Powers of two table
• Latency numbers every programmer should know

System design interview questions with solutions

Распространенные задачи с обсуждением, кодом и диаграммами.

Решение находятся в директории solutions/.

Задача на проектирование
Pastebin.com (или Bit.ly)	Решение
Лента и поиск в Twitter (или Facebook)	Решение
Веб-сканер	Решение
Система управление личными финансами Mint.com	Решение
Структура данных для социальной сети	Решение
Хранилище типа ключ-значение для поисковика	Решение
Рейтинг продаж по категориям в Amazon	Решение
Система, которая масштабируется до миллиона пользователей на AWS	Решение
Добавьте задачу	Решение

Design Pastebin.com (or Bit.ly)

Требования и решение

Design the Twitter timeline and search (or Facebook feed and search)

Требования и решение

Design a web crawler

Требования и решение

Design Mint.com

Требования и решение

Design the data structures for a social network

Требования и решение

Design a key-value store for a search engine

Требования и решение

Design Amazon's sales ranking by category feature

Требование и решение

Design a system that scales to millions of users on AWS

Требования и решение

Object-oriented design interview questions with solutions

Распространенные задачи с обсуждением, кодом и диаграммами.

Решение находятся в директории solutions/.

Внимание, этот раздел находится в стадии разработки

Задачи на проектировние
Хэш таблица	Решение
Кэширование с удалением давно используемых (Least recently used - LRU)	Решение
Центр обработки звонков	Решение
Колода карт	Решение
Парковка	Решение
Чат сервер	Решение
Циклический массив	Contribute
Добавьте задачу	Contribute

System design topics: start here

Только начинайте изучать проектирование систем?

Для начала, вам понадобится понимание базовых принципов, как они используются, их преимущества и недостатки.

Step 1: Review the scalability video lecture

Лекция по масштабированию в Гарварде

• Темы:
  • Вертикальное масштабирование
  • Горизонтальное масштабирование
  • Кэширование
  • Балансировка нагрузки
  • Репликация баз данных
  • Секцирование (Partitioning) баз данных

Step 2: Review the scalability article

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

• Темы:
  • Клонирование
  • Базы данных
  • Кэши
  • Асинхронность

Next steps

Далее, изучим компромиссы в общем виде:

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

Помните, что везде необходимы компромиссы.

Далее, изучем более детально DNS, CDN, балансировщики нагрузки и другие темы.

Performance vs scalability

Сервис считается масштабируемым, если его производительность растет пропорционально добавленным ресурсам. Обычно под увеличением производительности подразумевают увеличение количества обрабатываемых единиц работы. Однако, это может быть и обработка более крупных единиц работы, как, например, при росте объема данных.¹

Иначе говоря:

• если у вас проблемы с производительностью, ваша система медленная для одного пользователя;
• если у вас проблемы с масштабируемостью, ваша системы быстрая для одного пользователя, но становится медленной под большой нагрузкой.

Source(s) and further reading

• A word on scalability
• Scalability, availability, stability, patterns

Latency vs throughput

Задержка - это время, необходимое для выполнения действия или достижения некоторого результата.

Пропускная способность - это количество такие действий или результататов в единицу времени.

Обычно следует стремиться к максимальной пропускной способности, при этом сохраняя задержку приемлимой.

Source(s) and further reading

• Understanding latency vs throughput

Availability vs consistency

CAP theorem

Источник: CAP theorem revisited
Дополнительный источник: Wikipedia

В распределённый системах можно обеспечить только два из трех свойств, указанных ниже:

• Согласованность данных (Consistency) - каждый запрос на чтение возвращает самые актуальные данные либо ошибку.
• Доступность (Availability) - любой запрос возвращает результат, но без гарантии, что он содержит самую актуальную версию данных.
• Устойчивость к разделению (Partition Tolerance) - система продолжает работать, несмотря на произвольное разделение узлов системы из-за проблем с сетью.

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

CP - consistency and partition tolerance

При таком подходе ожидание ответа от узла может привести к ошибке - истечению времени ожидания (timeout error). CP решение хорошо подходит для систем, где необходима атомарность операций чтения и записи.

AP - availability and partition tolerance

При таком решении ответы на запросы возвращают данные, которые могут быть не самыми актуальными. Операция на запись может занять некоторое время, если придется ожидать восстановления потерянного соединения с одним из узлов распределённой системы.

AP решение подходит для систем, где система должна продолжать работать несмотря на внешние ошибки и допустима eventual consistency.

Source(s) and further reading

• CAP theorem revisited
• A plain english introduction to CAP theorem
• CAP FAQ

Consistency patterns

В распределённой системе можете существовать несколько копий одних и тех же данных. Для достижения согласованности данных, получаемых клиенстким приложением, существует несколько подходов синхронизации этих копий.

Weak consistency

После операции записи данных, операция чтения может увидеть эти данные, а может и не увидеть. Используется подход, при котором можно сделать как можно лучше, но с учетом данной ситуации.

Этот подход используеются в таких системах, как memcached. Слабая согласованность применяется в таких системах как VoIP, видео чаты и игры реального времени на несколько игроков.

Eventual consistency

После операции записи данных, операция чтения в конечном счете увидит эти данные (обычно в течение нескольких миллисекунд). Данных в таком случае реплицируются асинхронно.

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

Strong consistency

После операции записи данных, операция чтения увидит эти данны. Данные реплицируются синхронно.

Такой подход используеются в файловых системаях и реляционных БД. Сильная согласованность хорошо подходит для систем, где требуются транзакции.

Source(s) and further reading

• Transactions across data centers

Availability patterns

Для обеспечения высокой доступности существует два основных паттерна: отказоустойчивость и репликация.

Fail-over

Active-passive

В таком режиме, активный и пассивный сервер, находящийся в режиме ожидания, обмениваются специальными сообщениями - heartbeats. Если такой сообщение не приходит, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.

Время простоя определяется в каком состоянии находится пассивный сервер:

• горячее (hot) ожидание - сервер уже работает
• холодное (cold) ожидание - сервер должен быть запущен.

Только активный сервер может обрабатывать клиентские запросы.

Active-active

В таком режиме, оба сервера обрабатывают клиентские запросы, распределяют нагрузку между собой.

Если сервера имеют общий доступ, то публичные IP адреса обоих серверов должны быть зарегистрированы в DNS. Если сервера находятся во внутренней сети, то клиентское приложение знать про оба сервера.

Режим "активный-активный" также известен как "ведущий-ведущий".

Disadvantage(s): failover

• Отказоустойчивость делает систему более сложной и требует большего количества аппаратного обеспечения.
• Существует вероятность потери данных, если данных не успели реплицироваться во время переключения активного и пассивного серверов.

Replication

Master-slave and master-master

Эта тема обсуждается далее в разделе Database:

• Master-slave replication
• Master-master replication

Availability in numbers

Доступность обычно измеряется как сотношение времени, когда система доступна ко всему промежутку времени измерения. Обычно это количество девяток. Говорят, что сервис с доступностью 99.99%, имеет доступность в четыре девятки.

99.9% availability - three 9s

Длительность	Допустимое время простоя
Время простоя в год	8ч 45мин 57сек
Время простоя в месяц	43мин 49.7сек
Время простоя в неделю	10мин 4.8сек
Время простоя в день	1мин 26.4сек

99.99% availability - four 9s

Длительность	Допустимое время простоя
Время простоя в год	52мин 35.7сек
Время простоя в месяц	4мин 23сек
Время простоя в неделю	1мин 5сек
Время простоя в день	8.6сек

Availability in parallel vs in sequence

Если сервис состоит из нескольких компонентов, которые могут отказать в обслуживании, доступность сервиса зависит от того, как связаны эти компоненты - последовательно или параллельно.

In sequence

Общая доступность уменьшается, если два компонента (например, Foo и Bar) с доступностью менее 100% связаны последовательно:

Доступность (Общая) = Доступность (Foo) * Доступность (Bar)

In parallel

Общая доступность увеличивается, если два компонента с доступностью менее 100% связаны параллельно:

Доступность (Общая) = 1 - (1 - Доступность (Foo)) * (1 - Доступность (Bar))

Domain name system

Источник: DNS security presentation

Система домменных имен (DNS) преобразует доменное имя (например, www.example.com) в IP адрес.

DNS иерархична и имеет несколько корневых серверов. Информацию о том, какой DNS сервер надо использовать, предоставляется вашим маршрутизатором или интернет-провайдером. Нижестоящие DNS сервера кэшируют таблицы соответствия хостов и IP адресов, которые могут устаревать из-за задержки обновления. Результаты преобразования могут быть закэшированы браузером или операционной системой на определенное Время жизни (Time to live - TTL)

Типы записей:

• Запись NS (name server) - указывает DNS сервер для вашего домена/поддомена.
• Запись MX (mail exchange) - указывает сервера электронной почты для получения сообщений.
• Запись A (address) - связывает имя с IP адресом.
• CNAME (canonical) - связывает имя с другим именем, записью CNAME (example.com to www.example.com) или записью А.

Такие сервисы, как CloudFlare и Route 53 предоставляют управлемые DNS сервисы. Некоторые DNS сервисы могут направлять трафик, используя различные методы:

• взвешенный циклический (Weighted round robin):
  • предотвращает попадания трафика на сервера, находящиеся на обслуживании
  • балансирует трафик для кластера, размер которого может меняться
  • может использоваться для A/B тестирования
• на основе задержки отклика серверов
• на основе геораспределения серверов

Disadvantage(s): DNS

• Запрос на DNS сервер занимает некоторое время, которое может быть сокращено, используя кэширование, описанное выше.
• Управление DNS серверами может быть трудоёмким и поэтому обычно они управляются правительствами государств, интернет-провайдерами и большими компаниями
• DNS серверы могут подвергаться DDoS-атакам, в результате пользователи не могут получить доступ к сервисам, например Twitter, не зная его IP адреса(-ов).

Source(s) and further reading

• DNS architecture
• Wikipedia (ru)
• DNS articles

Content delivery network

Источник: Why use a CDN

Сеть доставки содержимого (Content Delivery Network, CDN) - это глобальная распределённая сеть прокси-серверов, которые доставляют содержимое с серверов, наиболее близко находящихся к пользователю. Обычно в CDN размещаются статические файлы, такие как HTML/CSS/JS, фотографии и видео. Некоторые сервисы, как, например Amazon CloudFront, поддерживают доставку динамического содержимого. DNS запрос на сайт даст ответ на какой DNS сервер клиент должен делать запрос.

Push CDNs

Содержимое Pull CDN обновляется тогда, когда оно обновлеятся на сервере. Разработчик сайта загружает содержимое на CDN и обновляет соотвествующие URL адреса, чтобы они указывали на CDN. Далее, можно сконфигурировать время жизни содержимого в CDN и когда оно должно быть обновлено. Загружается только новое или обновленное содержимое, минимизируя трафик и увеличивая объем хранящихся данных в CDN.

Pull CDNs

Pull CDN загружает новое содержимое при первом обращении пользователя. Разработчик сайта оставляет содержимое на своем сервере, но обновляет адреса, чтобы они указывали на CDN. В результате, запрос обрабатывается медленее, ожидая пока содержимое будет закэшировано в CDN.

Время жизни (Time to live - TTL) определяет как долго содержимое будет закэшировано. Pull CDN минимизирует объем хранящихся данных в CDN, но может привести к дополнительному трафику, если время жизни в CDN истекло, а файл на сервере изменен не был.

Pull CDN подходит для загруженных сайтов. Трафик в таком случае распределяется более равномерно и в результате в CDN хранится только то содержимое, к которому обращались недавно.

Disadvantage(s): CDN

• Стоимость CDN может быть высока и зависит от объема трафика, но стоит иметь в виду и дополнительные расходы, которые будут если CDN не использовать.
• Содежимое в CDN может оказаться устаревшим, если оно будет обновлено до того, как истечет время жизни (TTL).
• Исходные URL ссылки должны быть изменены и указывать на CDN.

Source(s) and further reading

• Globally distributed content delivery
• The differences between push and pull CDNs
• Wikipedia (ru)

Load balancer

Source: Scalable system design patterns

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

• предотвращения запроса на неработающий сервер
• предотвращения чрезмерной нагрузки ресурсов
• избежания единой точки отказа

Балансировщики нагрузки могут быть аппаратными (дорогой вариант) или программными (например, HAProxy).

Дополнительные плюсы:

• SSL-терминация - расшифровка входящих запросов и шифровка ответов; в таком случае бэкенд-сервера не тратят свои ресурсы на эти потенциально трудоемкие операции
  • нет необходимости устанавливать X.509 сертификаты
• Сохранение сессии - выдает куки и перенаправляет клиенсткий запрос на тот же сервер в случае, если сами веб-приложения не хранят сессии.

Для защиты от сбоев, можно использовать вместе несколько балансировщиков в active-passive или active-active режиме.

Балансировщики могут направлять трафик опираюсь на различные метрики, включая:

• случайно
• наименее загруженные сервер
• сессия/куки
• взвешенный циклический (Weighted round robin)
• Layer 4
• Layer 7

Layer 4 load balancing

Для распределения запросов балансировщики 4го уровня используют транспортный уровень модели OSI transport layer. Обычно, используются IP адрес и порт источника и получателя из заголовков пакетов, но не из их содержимого. Балансировщики этого уровня перенаправляют сетевые пакеты с серверов, используя Network Address Translation (NAT).

Layer 7 load balancing

Для распределения запросов балансировщики 7го уровня используют прикладной уровень модели OSI application layer. Для этого могут быть задействованы заголовок, сообщение и куки. Балансировщики на этом уровне прерывают сетевой трафик, сканируют сообщение, принимают решение, куда отправить запрос и открывают соединение с выбранным сервером. Например, они могут отправить запрос на видео на видео-сервер, а запрос на биллинг - на сервера с усиленной безопасностью.

Балансировка на 4м уровне быстрее и требует меньше ресусров, чем на 7м уровне, но имеет меньшую гибкость. Хотя на современном аппаратном обеспечении эта разница может быть незаметна.

Horizontal scaling

Балансировщики нагрузки могут быть использованы для горизонтального масштабирования, улучшая производительность и доступность. "Масштабирование вширь" используя стандартные сервера дешевле и приводит к более высокой доступности, чем "масштабирование вверх" одного сервера с более дорогим аппаратным обеспечением (Вертикальное масштабирование). Так же проще найти и специалиста, который умеет работать со стандартным аппаратным обеспечением, чем со специализированными Enterprise-системами.

Disadvantage(s): horizontal scaling

• Горизонтальное масштабирование увеливает сложность система и предполагает клонирование серверов:
  • Сервера не должны хранить состояние, например сессию или изображение пользователя
  • Сессии должны хранится в центразиванном хранилище, например в database (SQL, NoSQL) или в cache (Redis, Memcached)
• С увеличением количества серверов, принимающие сервера на следующем уровне должны обрабатывать больше одновременных запросов

Disadvantage(s): load balancer

• Балансировщик нагрузки может стать узким место в производительности системы, если он неправильно сконфигурирован или его аппаратное обеспечение слишком слабое.
• Балансировщик нагрузки позволяет избежать единой точки отказа, но увеличивает совокупную сложность всей системы.
• Единственный балансировщик становится единой точкой отказа, использование нескольких балансировщиком еще больше усложняет систему.

Source(s) and further reading

• NGINX architecture
• HAProxy architecture guide
• Scalability
• Wikipedia
• Layer 4 load balancing
• Layer 7 load balancing
• ELB listener config

Reverse proxy (web server)

Source: Wikipedia

Обратный прокси-сервер - это веб-сервер, который централизует внутренние сервисы и предоставляет уницифицированный интерфейс для доступа из публичной сети. Клиенсткие запросы перенаправляются на сервер, который их будет обрабабывать, и затем обратный прокси возвращает ответ клиенту.

Дополнительные преимущества:

• повышенная безопасность - скрывает информацию о бэкенд-серверах, блокирует IP адреса, ограничивает допустимое количество соединений на клиента
• повешенная масштабируемость и гибкость - клиенсткое приложение знает только IP адрес прокси-сервера, таким образом можно менять количество серверов или изменять их конфигурацию
• SSL терминация - расшифровка входящих запросов и шифровка ответов; в таком случае бэкенд-сервера не тратят свои ресурсы на эти потенциально трудоемкие операции
  • нет необходимости устанавливать X.509 сертификаты
• Сжатие - сжатие ответов сервера клиенту
• Кэширование - возвращает ответы для закэшированных запросов
• Статическое содержимое - предоставляет статическое содержимое напрямую:
  • HTML/CSS/JS
  • Фотографии
  • Видео
  • и т.д.

Load balancer vs reverse proxy

• Использование балансировщика нагрузки полезно при наличии нескольких серверов. Часто балансировщики направляют трафик на сервера, выполняющие одинаковую функцию.
• Обратный прокси-сервер может быть полезен даже при использовании одного веб-сервера или сервера приложений, предоставляе преимущества, описанные в предыдущей секции
• Такие решения, как NGINX и HAProxy могут поддерживать как реверс-прокси 7го уровня, так и балансировку нагрузки

Disadvantage(s): reverse proxy

• Использование обратного прокси-сервера увиличивает сложность системы в целом
• Использование одного прокси-сервера создает единую точку отказа. Настройка нескольких обратных прокси-серверов (Аварийное переключение) еще больше усложняет систему.

Source(s) and further reading

• Reverse proxy vs load balancer
• NGINX architecture
• HAProxy architecture guide
• Wikipedia (ru)

Application layer

Source: Intro to architecting systems for scale

Разделение веб-уровня и уровня приложение (так же известного как уровень платформы) позволяет масштабировать и настраивать оба уровня независимо. Для добавления нового API может понадобиться добавление нового сервера на уровне приложение, но необязатльно на веб-уровне. Принцип единой отвественности подразумевает созданте небольших и автономных сервисов, который работают вместе. Небольшие команды с небольшими сервисами могут быстрее расти.

Worker-сервера на уровне приложений позволяют поддерживать asynchronism.

Microservices

Микросервисная архитектура может быть описана как набор независимо развёртываемых, небольших, модульных сервисов. Каждый сервис работает как независый процесс и взаимодействует на основе предустановленного легковесного протокола для обслуживания бизнес задачи. ¹

Микросервисы Pinterest могут включать: профиль пользователя, подписчик, лента, поиск, загрущка фото и т.д.

Service Discovery

Ведя учет зарегистрованных имен, адресов и порто, такие системы как Consul, Etcd, и Zookeeper помогают сервисам находит друг друга. Проверки состояния Health checks позволяют убедиться в работоспособности сервера с помощью HTTP запросы. Consul и Etcd имеют key-value store, которое может быть полезно для хранения конфигурации и других общих данных.

Disadvantage(s): application layer

• Добавление уровня приложений со слабосвязанными сервисами требует другого подхода для архитектуры и процессов (в отличие от монолитной системы).
• Микросервисная архитектура усложняет развертывание и эксплуатацию сервисов.

Source(s) and further reading

• Intro to architecting systems for scale
• Crack the system design interview
• Сервис-ориентированная архитектура
• Introduction to Zookeeper
• Here's what you need to know about building microservices

Database

Источник: Scaling up to your first 10 million users

Relational database management system (RDBMS)

Реляционная база данных (SQL) - это набор данных, организованных в виде таблиц.

ACID - описывает набор свойст транзакций для реляционных баз данных.

• Атомарность (Atomicity) - каждая транзакция выполняется либо целиком, либо не выполняется совсем (откатывается)
• Согласованность (Consistency) - любая транзакция переводит базу данных из одного правильного состояния в другое правильное состояние, сохраняя согласованность данных
• Изолированность (Isolation) - параллельное выполнение транзакцией должно иметь такие же результаты, как и их последовательное выполнение
• Стойкость (Durability) - после завершение транзакции, данные должны остаться сохранёнными

Существует ряд подходов для масштабирования реляционных баз данных:

• репликация "ведущий-ведомый"
• репликация "ведущий-ведущий"
• федерализация
• шардирование
• денормализация
• SQL тюнинг

Master-slave replication

Ведущий сервер работает на чтение и запись, реплицируя записи на один или более ведомых серверов. Ведомый сервер работает только на чтение. Ведомые сервера могу реплицировать на дополнительные ведомые сервера (как в древовидной структуре). Если ведущий сервер перестает работать, система продолжает работать в режиме только на чтение до тех пор, пока один из ведомых серверов не станет ведущим, или пока новый ведущий сервер не будет создан.

Источник: Scalability, availability, stability, patterns

Disadvantage(s): master-slave replication

• Для переключения ведомого сервера в ведущий необходима дополнительная логика
• См. Disadvantage(s): replication для пунктом, характерных для подходов "ведущий-ведомый" и "ведущий-ведущий".

Master-master replication

Оба ведущих сервера работают на чтение и запись и координирует операции записи между собою. Если один из ведущих серверов перестают работать, система может продолжать работать на чтение и запись.

Источник: Scalability, availability, stability, patterns

Disadvantage(s): master-master replication

• Необходим балансировщик нагрузки или понадобиться изменить логику приложение для опеределения куда будет идти запись.
• Большинство систем "ведущий-ведущий" либо слабо согласованы (нарушая ACID) либо имеют большую задержку из-за необходимости синхронизации.
• При возрастании количества серверов на запись (ведущих) возрастает задержка и возникает необходимость разрешения конфликтов.
• См. Disadvantage(s): replication для пунктом, характерных для подходов "ведущий-ведомый" и "ведущий-ведущий".

Disadvantage(s): replication

• Существует риск потери данных, если ведущий сервер перестает работать до того, как новые данные будут реплицированы на другие сервера.
• Операции записи реплицируются на ведомый сервера. Если совершается много операций на запись, ведомые сервера могут быть перегружены реплицированием этих операций, влияя на производительность операций на чтение.
• С ростом количества ведомых серверов увеличивается объем репликации, что приводит к задержке репликации.
• На некоторых системах, запись на ведущем сервере может делаться в несколько потоков, выполняемых параллельно. Запись на ведомых серверах происходит последовательно в один поток.
• Репликация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.

Source(s) and further reading: replication

• Scalability, availability, stability, patterns
• Multi-master replication

Federation

Source: Scaling up to your first 10 million users

Федерализация (или функциальное разделение) разбивает базы данных по функциям. Например, вместо одной монолитной базы данных, можно создать три отдельных базы данных: форум, пользоватили и товары, что приведет к меньшему количествую операций чтения и записи в каждую базу данных и, как следствие, сократить задержку репликации. Меньшие базы данных позволяют хранить больше данных в памяти, что приводит к более оптимальному использованию кэширования. Из-за отстуствие единого ведущего сервера, операции записи можно делать параллельно, увеличавая пропускную способность.

Disadvantage(s): federation

• Федерализация неэффективна, если схема базы данных требует больших функций или таблиц.
• Неободимо изменить логику приложения, чтобы определить, с какими базами данных работать.
• Операция соединения данных (JOIN) становится сложнее server link.
• Федерализация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.

Source(s) and further reading: federation

• Scaling up to your first 10 million users

Sharding

Источник: Scalability, availability, stability, patterns

Шардирование распределяет данны между разными базами данных так, что каждя база данных управляет только частью данных. Например, с увеличением количества пользователей в базу данных пользователей добавляются новые сервера (шарды).

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

Расптространненый подход шардирования таблицы пользователей основан на разделении по имени или местоположению.

Disadvantage(s): sharding

• Логика приложения должна быть адаптирована к работе с шардами, что может привести к более сложным SQL запросам.
• Данные могут неравномерно распределяться среди шардов. Например, использование данных активных пользователей, находящихся на одном шарде, увеличивают нагрузку на него.
  • Балансировка усложняет систему. Функция шардирования, основанная на consistent hashing может уменьшить общий объем передаваемых данных.
• Соединение данных (JOIN) из нескольких шардов сложнее
• Шардирование требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.

Source(s) and further reading: sharding

• The coming of the shard
• Shard database architecture
• Consistent hashing

Denormalization

Денормализация - это попытка улучшить скорость чтения за счет производительности записи. Избыточные копии данных записываюся в несколько таблиц для избежания сложных операций соединения данных. Некоторый СУБД, например PostgreSQL и Oracle поддерживают материализованное представление, которые выполнюят задачу хранения избыточных данных и поддержку их согласованности.

При использовании federation и sharding, данные становятся распределенными. В результате выполнение операций соединения данных усложняется. Денормализация может позволить избавиться от необходимости в сложных JOIN запросах.

В большинстве систем, количество операций на чтение значительно больше операций на запись (100:1, или даже 1000:1). Операция на чтение в результате сложного соединения данных может быть очень ресурсоемкой и требованть значительного времени, потраченного на операции c жестким диском.

Disadvantage(s): denormalization

• Данные дублируются.
• Ограничения могу помочь поддерживать избыточные копии данных в актуальном состоянии, но увиличивают сложность архитектуры базы данных
• Денормализованная база данных под большой нагрузкой может работать медленее, чем её нормализованный аналог.

Source(s) and further reading: denormalization

• Денормализация

SQL tuning

SQL тюнинг - это обширная тема, описанная во многих книгах).

Очень важно проводить бенчмарки и профилирование для имитации и обнаружения узких мест.

• Бенчмарк - эталонный тест производительности, имитация высокой нагрузки с помощью таких средств, как ab.
• Профилирование - отслеживание проблем производительность с помощью таки средства, как slow query log

Проведение бенчмарков и профилирования может указать на следующие шаги оптимизации.

Tighten up the schema

• Запись в MySQL на смежные блоки для быстрого доступа.
• Использование CHAR вместо VARCHAR для полей с фиксированной длиной.
  • CHAR обеспечивает быстрый произвольный доступ, в случае с VARCHAR необходимо найти конец строки для перехода на следующую.
• Использование TEXT для больших фрагментов текста (например, блог-посты). TEXT позволяет делать булевый поиск. Использование поля типа TEXT приводит к хранению указателя на диске, которые иоспользуется для поиска этого блока.
• Использование INT для больших числе до 2^32.
• Использование DECIMAL для денежных едениц для избежания ошибок, связанных с представлением в формате с плавающей точкой.
• Избежание хранения большиъ BLOBS, вместо этого хранение указателя на место хранения объекта.
• Установка ограничения NOT NULL, где возможно, для улучшения производительности (improve search performance).

Use good indices

• Запрос столбцов (включая операторы SELECT, GROUP BY, ORDER BY, JOIN) может быть быстрее с индексами.
• Индексы обычно представляют собой самобалансирующиеся B-деревья, которые хранят данные отсортированными, позволяют поиск, последовательный доступ, вставку и удаление с логарифмической сложностью.
• Создание индексы может потребовать хранения данных в памяти, требуя больше места.
• Операции записи могут быть медленне, так как индекс тоже необходимо обновлять.
• При загрузке большого объема данных отключение индексов может помочь для ускорения этой операции; индексы в таком случае обновляются после загрузки данных.

Avoid expensive joins

• Denormalize, если необходимо повысить производительность.

Partition tables

• Разбиение таблицы, поместив часто используемые данные в отдельную таблицу, для того, чтобы хранить ее в памяти.

Tune the query cache

• В некоторых случаях, кэширование запросов (query cache) может привести к проблемам с производительностью (performance issues).

Source(s) and further reading: SQL tuning

• Tips for optimizing MySQL queries
• Is there a good reason i see VARCHAR(255) used so often?
• How do null values affect performance?
• Slow query log

NoSQL

NoSQL - это набор данных, представленных в виде базы ключ-значение, документориентированной базы данных, колоночной базы данных или графовой база данных. Данны денормализованы и операции соединения данных обычно происходят на уровне кода. Большинство NoSQL хранилищ не поддерживают ACID свойств транзакий и характеризуются согласованностью в конечном счете.

Для описания свойств NoSQL баз данных используют BASE свойства. Согласно CAP Theorem, BASE придерживается доступности данных, а не их согласованности.

• В целом доступные - система гарантирует доступность.
• Неокончательное (soft) удаление - состояние ситемы может со временем измениться, даже без дополнительный операций.
• Согласованность в конечном счете (eventual consistency) - данные в системе станут согласованными в течение некоторого времени, если в течение этого времени не будут приходить новые данные.

Вместе с выбором между SQL or NoSQL, надо сделать выбор типа NoSQL базы данных, которая подходит для вашего сценария использования. В следующей секции представлены базы ключ-значение, документориентированные базы данных, колоночные базы данных или графовые база данных.

Key-value store

Абстракция: хэщ-таблица

База данных типа ключ-значение обычно позволяет выполнять операции чтение и записи со сложностью O(1) и используют оперативную память или SSD. Эти базы данных могут поддерживать лексикографический порядок, позволяя эффективно выполнять запросы на диапазон ключей. Базы этого типа позволяют хранить мета-данные вместе с данными.

Такие базы данных имеют высокую производительность и обычно используют для простых моделей данных или для быстро изменяющихся данных, таких как кэши, находящиейся в оперативной памяти. Обычно они предоставляют ограниченный набор действий. Поэтому сложность смещается на уровень приложение в том случае, если необходимы дополнительные действия.

Базы данных типа ключ-значнеие являются основой для более сложных система, таких как Документоориентированных базы данных, и, в некоторых случаях, графовые базы данных.

Source(s) and further reading: key-value store

• База данных "ключ-значение"
• Disadvantages of key-value stores
• Redis architecture
• Memcached architecture

Document store

Абстракция: база данных "ключ-значение" с документами в качестве значения

Документнориентированная база данных работает с документами (XML, JSON, бинарные и др.), где документ хранит все информацию об объекте. Такие базы данные предоставляют API или язык для запросов по внутренней структуре самих документов. Обратите внимание, что такая же функциональность может быть доступна и для метаданных, тем самым размывая разницу между этими двумя типа данных.

В зависимости от реализации, документы могут быть организованы по коллекциям, меткам, метаданным или директориям. Документы могут быть организованы и сгруппированы вместе, и одновременно иметь поля, которых нет в других документах.

Такие базы данных как MongoDB и CouchDB предоставляют SQL-подобный язык для выполнения сложных запросов. DynamoDB работает с данными в виде "ключ-значение" и с документами.

Документоориентированные базы данных предоставляют высокую гибкость и часто используются для работы с данными, структура которых может меняться.

Source(s) and further reading: document store

• Документоориентированная СУБД
• MongoDB architecture
• CouchDB architecture
• Elasticsearch architecture

Wide column store

Source: SQL & NoSQL, a brief history

Абстракция: вложенная ассоциативная таблица ColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>>

Основной единицой данных в колоночных базах данных является колонка - пара имя/значение. Колонки могут быть сгруппированы в семейства колонок (по аналогии с SQL таблицей). Следующим уровнем будет супер-семейство колонок. Значение каждой колонки можно получить по ключу строки. Все колонки с одинаковым ключом строки формируют строку. Каждое значение содержит временную метку для версионности и разрешения конфликтов.

Google представили Bigtable, как первую колоночную базу данных, которая была создана под влиянием HBase, часто используемой в экосистеме Hadoop, и Cassandra от Facebook. BigTable, HBase, and Cassandra и другие базы данных этого типа хранят ключи в лексикографическом порядке, позволяя делать эффективные запросы по диапазону ключей.

Колоночные базы данных имеют высокую доступность и масштабируемость. Часто они используются для очень больших объемов данных.

Source(s) and further reading: wide column store

• SQL & NoSQL, a brief history
• Bigtable architecture
• HBase architecture
• Cassandra architecture

Graph database

Source: Graph database

Абстракция: граф

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

Графовые базы данных имеют высокую производительность для моделей данных со сложными связями, как в социальных сетях. Они относительно новые и не пока не используются широко. Может быть сложно найти средства и ресурсы для их разработки. Получить доступ ко многим графам можно только с помощью REST APIs.

Source(s) and further reading: graph

• Графовая база данных
• Neo4j
• FlockDB

Source(s) and further reading: NoSQL

• Explanation of base terminology
• NoSQL databases a survey and decision guidance
• Scalability
• Introduction to NoSQL
• NoSQL patterns

SQL or NoSQL

Source: Transitioning from RDBMS to NoSQL

Причины использовать SQL:

• Структурированные данные
• Строгая схема
• Реаляционные данные
• Необходимость сложных соединений (JOIN)
• Транзакции
• Понятные шаблоны масштабирования
• Широко используются: разработчики, сообщество, код, средства и т.д.
• Поиск по индексу очень быстрый

Причины использовать NoSQL:

• Частично-структурированные данные
• Динамическая или гибкая схема данных
• Нереляицонные данные
• Нет необходимости в сложных соединениях (JOIN)
• Хранение большого количества данных (TB или PB)
• Очень большая нагрузка связанная с работой с данными
• Большая пропуская способность для IOPS (количество операций ввода-вывода в секунду)

Примеры данных, хорошо подходящих для NoSQL:

• Скоростное сохранение clickstream данных и данных журналирования (logs)
• Список лидеров или общий счет
• Временные данные, например, корзина
• Таблицы с частым доступом (горячие таблицы)
• Метаданные или данные для поиска

Source(s) and further reading: SQL or NoSQL

• Scaling up to your first 10 million users
• SQL vs NoSQL differences

Cache

Источник: Scalable system design patterns

Кэширование улучшает время загрузки страницы и может уменьшить нагрузку на сервера и базы данных. При таком подходе, диспетчер сначали проверяет, делался ли запрос ране, чтобы найти ответ, который уже на него возвращался, сократив при этом время выполнения текущего запроса.

Базы данных работают оптимальным образом при равномерном распределении операций чтения и записи между их партициями (partitions). Популярные элементы могут нарушить равномерность распределения, создавая узкие места. Добавление системы кэширование перед базой данных может позволить сгладить неравномерность поступающего трафика.

Client caching

Системы кэширования могут находиться на клиентской стороне (ОС или браузер), server side, или в выделенном уровне для кэширования.

CDN caching

CDNs считаются одним из видов кэширования.

Web server caching

Reverse proxies и системы такие системы кэширование как Varnish могут выдавать как статический, так и динамический контент. Веб-сервера тоже могут кэшировать запросы, возвращая ответы не обращаюсь к серверам приложений.

Database caching

База данных обычно включает какое-то кэширование в конфигурации по умолчанию, которое оптимизировано для стандартных сценариев использования. Настройка этих параметров для конкретных шаблонов использования данных может еще больше увеличить её производительность.

Application caching

Системы кэширования в памяти (например, Memcached и Redis) являются хранилищами типа "ключ-значение", которые находятся между вашим приложением и хранилищем данных. Они обычно быстрее, так как данных хранятся в оперативной памяти, а не на жестком диске, как это обычно бывает в случае с базами данных. Количество оперативной памяти имеет больше ограничений, чем жесткий диск, поэтому алоритмы очистки кэша, как например вытеснение давно неиспользуемых (Least recently used, LRU) помогают удалять из кэша "холодные" записи и оставлять в памяти "горячие".

Redis включает дополнительную функциональность:

• возможность сохранения данных (из памяти на диск)
• встроенные структуры данных, например сортированные множества или списки

Существует несколько уровней кэширования, которые можно обобщить в две категории: "запросы к БД" и "объекты":

• записи БД
• запросы
• сформированные сериализуемые объекты
• сформированный HTML

Как правило, стоит избегать кэширования файлов, так как такой подход усложняет клонирование и автоматическое масштабирование.

Caching at the database query level

При таком подходе результат сохраняется с ключом, которым является вычисленное хэш-значение для запросы в базу данных. Такой подход имеет ряд недостатков:

• Тяжело удалить закэшированный результат сложных запросов
• Если меняется значение одной ячейки данных, необходимо удалить все запросы, который могут содержать эти данные

Caching at the object level

При таком подходе данные рассматриваются как объекты, аналогично объектам в коде приложения. Приложение собирает данные из базы в объект класса или структуру(ы) данных:

• Объект удаляется из кэша, если структура данных, которую он представляет, изменилась
• Возможна асинхронная обработка: новые объекты могуть собираться из текущий версий закэшированных объектов

Что можно кэшировать как объекты:

• Пользовательские сессии
• Полностью сформированные веб-страницы
• Потоки активности
• Графовые данные пользователя

When to update the cache

Для каждого сценария использования необходимо определять, какая стратегия очистки кэша подходит наилучшим образом, так как количество данных, которые можно хранить в системе кэширования, ограничено.

Cache-aside

Источник: From cache to in-memory data grid

Приложение читает данных из хранилища и записывает в него. Система кэширования не взаимодействует с хранилищем. Приложение выполняет следующие действия:

• Ищет элемент в кэше, которой там ещё нет
• Загружает данные из БД
• Добавляет элемент в кэш
• Возвращает результат клиенту

def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user

Обычно так используется Memcached.

Последующие запросы на чтение данных, находящиейся в кэши, выполняются быстро. Также такой подход известен как ленивая загрузка. Только запрашиваемые данные попадают в систему кэширование, и не происходит его заполнения данными, которые не запрашиваются.

Disadvantage(s): cache-aside

• Если запришиваемые данные отсутствуют в кэше, выполняется три дополнительных действия, которые могут привести к заметной задержке
• Данные могут устареть, если они обновляются в БД. Для смягчение последствий этой проблемы используют время жизни (TTL), которое вызывает обновление элемента в кэше, либо делают сквозную запись
• Когда выходит из строя сервер кэширования, он заменяется новым сервером с пустым кэшем, что увеличивает задержку.

Write-through

Источник: Scalability, availability, stability, patterns

Приложение использует систему кэширования, как основной источник данных, считывая и записывая данные в него. Система кэширования в свою очередь записывает и считывает данных из БД:

• Приложение добавляет и обновляет элемент в системе кэширования
• Система кэширования синхронно записывает данные в БД
• Возвращается результат

Код приложения:

set_user(12345, {"foo":"bar"})

Код системы кэширования:

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)

В целом, подход со сквозной записью является медленным из-за операции записи, но последующие операции чтения выполняются быстро. Пользователи предпочитают такие системы из-за допустимой задержки при обновлении данных, но не их чтении. Данные в системе кэширования не устаревают.

Disadvantage(s): write through

• Когда добавляется новый сервер из-за отказа другого, либо масштабироавние, его кэш не содержит никаких элементов, пока данные не будут обновляеться в БД. Использование "отдельного" кэша может помочь смягчить последствия этой проблемы
• Большая часть записываемых данных может вообще не использоваться. Использование времени жизни данных (TTL) может смягчить последствия этой проблемы.

Write-behind (write-back)

Источник: Scalability, availability, stability, patterns

При таком подходе приложение делает следующее:

• Добавляет/обновляет элемент в системе кэширования
• Асинхронно делает запись в БД, улучшая скорость записи

Disadvantage(s): write-behind

• Возможна потеря данных, если система кэширования выйдет из строя до сохранения данных в БД.
• Такую систему сложнее реализовать, чем "отдельный" или "сквозной" кэш.

Refresh-ahead

Источник: From cache to in-memory data grid

При таком подходе можно настроить автоматическое обновление закэшированных данных, к которым недавно обращались, не ожидая истечения их срока действия.

Кэширование методом "предварительного обновление" может уменьшить задержку, по сравнению с кэшем, который делает сквозное чтение, если можно точно определить, какие элементы могут быть запрошены в будущем.

Disadvantage(s): refresh-ahead

• Неточное определение элементов, которые могут понадобиться в будущем, может привести к ухудшению производительности.

Disadvantage(s): cache

• Необходимость поддерживать согласованность данных в кэше и источнике данных, таком как БД, с помощью инвалидации кэша.
• Инвалидация кэша является сложной задачей, и включаещей дополнительную задаче по определению времени, когда кэш нужно обновлять.
• Необходимы изменения в приложении, например, добавление Redis или Memcached.

Source(s) and further reading

• From cache to in-memory data grid
• Scalable system design patterns
• Introduction to architecting systems for scale
• Scalability, availability, stability, patterns
• Scalability
• AWS ElastiCache strategies
• Кэш - Wikipedia

Asynchronism

Источник: Intro to architecting systems for scale

Асинхронные процессы позволяют сократить время запросов для трудоёмких операций по сравнению со случаями, когда эти операции выполняются синхронно. Они также могут помочь с выполением времязатратных операций, таких как периодическое агрегирование данных.

Message queues

Очереди сообщений позволяют принимать, хранить и доставлять сообщения. Если операция слишком медленная для синхронного выполнения, можно использовать очередь сообщений со следующим рабочим процессом:

• Приложение отправляет задачу в очередь, затем оповещает пользователя о состоянии задачи
• Рабочий процесс (воркер) берет задачу из очереди, выполняет её и посылает сообщение о том, что задача выполнена

При таком подходе пользователь не заблокирован и задача выполняется в фоне. В это время, клиентское приложение может частично обработать данные и сделать видимость выполнения. Например, сразу после публикации вашего сообщения в соц. сети, оно может появится в вашей ленте, но фактическая доставка этого сообщения фоловерам может занять некоторое время.

Redis - может использоваться как простой брокер сообщений (message broker), но сообщения могут быть утеряны.

RabbitMQ - широко распространен, но потребует адаптации к "AMQP" протоколу и поддержки серверов для его развертывания.

Amazon SQS - сервис, может иметь большую задержку и возможность доставки сообщений дважды.

Task queues

Очереди сообщений принимают задачи и связанные с ними данные, выполняют их, и затем доставляет их результаты. Они могут поддерживать планирование и использоваться для выполнения задач, которые требуют высоких вычислительных мощностей, в фоне.

Планирование есть в Celery, который в основном поддерживается на Python.

Back pressure

Если очередь достигает больших размеров, ее размер может стать больше памяти, что приведет к запросу элементов, которых нет в кэши, увеличению количества операций чтения с жесткого диска и ухудшению производительности. Обратное давление может помочь, ограничивая размер очереди и поддерживая высокую пропускную способность и хорошее время отклика для задач, которые уже находятся в очереди. Как только очередь заполнится, клиентские приложения получают 503 код состояния HTTP ("Сервис недоступен"). Клиенты могут повторить запрос позже, в том числе и с экспоненциальной выдержкой.

Disadvantage(s): asynchronism

• Для простых вычислений и процессов реального времени лучше подойдут синхронные операции, так как введение очередей добавит задержку и усложнят систему.

Source(s) and further reading

• It's all a numbers game
• Applying back pressure when overloaded
• Закон Литтла
• What is the difference between a message queue and a task queue?

Communication

Источник: OSI 7 layer model

Hypertext transfer protocol (HTTP)

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

Стандартный HTTP запрос состоний из глагола (метода) и ресурса (конечной точки (endpoint)). Ниже приведены распространенные HTTP методы:

Метод	Описание	Идемпотентность*	Безопасность	Кэшируемость
GET	Считывает ресурс	Да	Да	Да
POST	Считывает ресурс, или начинает какой-то процесс обработки данных	Нет	Нет	Да, если ответ содержит информацию об актуальности данных
PUT	Создает или замещает ресурс	Да	Нет	Нет
PATCH	Частично обновляет ресурс	Нет	Нет	Да, если ответ содержит информацию об актуальности данных
DELETE	Удаляет ресурс	Да	Нет	Нет

*Может быть вызван несколько раз, при этом результат будет всегда одинаковым.

HTTP - это протокол уровня приложений, который построен на более низкоуровненвых протоколах, таких как TCP и UDP.

Source(s) and further reading: HTTP

• What is HTTP?
• Difference between HTTP and TCP
• Difference between PUT and PATCH

Transmission control protocol (TCP)

Источник: How to make a multiplayer game

TCP - это протокол с установкой соединения, работающих поверх межсетевого протокола IP. Соединение устанавливается и завершается с помощью рукопожатия. Гарантия доставки пакетов в оригинальном порядке и без искажений получателю основана на:

• номерах последовательности и полем контрольной суммы
• подтверждении пакетов и автоматической повторной передаче.

Если отправитель не получает правильного ответа, пакеты будут отправление повторно. Если время ожидания истекает несколько раз, соединиение разрывается. TCP также реализует контроль потока и отслеживание перегрузок. Такие гарантии вызывают задержки и обычнго приводят к менее эффективной передаче по сравнению с UDP.

Для поддержики высокой пропускной способности, веб-сервера могут держать большое количество открытых TCP соединений, что приводит к использованию большого количества оперативной памяти. Ресурсозатратным можем быть поддержание большого количества открытых соединений между потоками веб-сервера и, например, сервером Memcached. В этом случае может помочь использование пула соединений и UPD там, где он может быть применим.

TCP полезен для приложений, которым необходимы высокая надежная, но менее требовательным ко времени, например веб-серверы, базы данных, SMTP, FTP, SSH.

Используйте TCP (а не UDP) в случаях, когда необходимо:

• сохранить данные неповрежденными
• наилучшим образом использовать пропускную способность сети автоматически

User datagram protocol (UDP)

Источник: How to make a multiplayer game

Source(s) and further reading: TCP and UDP

UPD не требует соединения. Датаграммы (по аналогии с пакетами данных) гарантированы только на уровне датаграммы. Датаграммы могут быть доставлены в другом порядке (отличном от того, в котором они были отправлены), либо не доставлены совсем. UDP не поддерживает контроля перегрузок. Из-за отсутствия гарантий TCP, обычно UDP является более эффективным.

UDP поддеживает широковещательную передачу данных, отправляя датаграммы всем устройствам подсети. Это полезно использовать вместе с DHCP, так как с клиентом, который еще не получил IP адрес, нельзя установить TCP соединение.

UPD менее надежный, но работает хорошо для приложений реального времени, например, VoIP, видеочатов, потоковой передачи данных и мультиплеерных игр реального времени.

Используйте UPD (а не TCP) в случаях, когда:

• вам необходима минимальная задержка передачи данных
• данных, которые пришли поздно, хуже, чем потеря данных
• вы хотите сами реализовать исправление ошибок

Remote procedure call (RPC)

Источник: Crack the system design interview

При использовании RPC, клиент вызывает выполнение процедуры в другом адрессном пространстве, обычно на удаленном сервере. Эта процедура запрограммирована для использования, как локальный вызова, абстрагируя детали взаимодействия сервера и клиенского приложения. Удаленные вызовы обычно медленее и менее надежны, чем локальные вызовы. Поэтому полезно различать удаленные вызовы от локальных. Популярными RPC фреймворками являются Protobuf, Thrift, и Avro.

RPC - это протокол на основе запроса и ответа:

• Клиентское приоложение - вызывает клиентскую процедуру-заглушку. Параметры передаются в стек, также как и с вызовом локальной процедуры.
• Клиентская процедура-заглушка - собирает идентификатор процедуры и её аргументы в сообщение для запроса.
• Клиентский модуль взаимодействия - ОС отправляет сообщение с клиента на сервер.
• Серверный модуль взаимодействия - ОС передает входящие пакеты серверной процедуре-заглушке.
• Серверная процедура-заглушка - разбирает входящее сообщение, вызывает процедуру по полученному идентификатору и передаёт ей полученные аргументы.
• Таким же образом, только в обратном порядке, идет ответ от сервера клиенту.

Примеры вызовов RPC:

GET /someoperation?data=anId

POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}

RPC сфокусированы на поведении системы. RPC обычно используются для достижения высокой производительности при внутренней передаче данных, так как можно использовать нативные вызовы, подходящие для ваших сценариев использования.

Используйте нативные библиотеки (SDK), когда:

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

REST API на основе HTTP часто используются для публичных API.

Disadvantage(s): RPC

• клиентские приложения RPC становятся сильно связанными с сервисной реализацией.
• необходимо делать новое API для каждой новой операции или сценария использования.
• отладка (debug) вызов RPC может быть непростой.
• вы, возможно, не сможете использовать существующие технологии как есть "из коробки". Например, могут понадобиться дополнительные действия для того, чтобы убедиться, что RPC запросы закэшированы на серверах системах кэширования таких, как Squid.

Representational state transfer (REST)

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

Существует четыре характеристики REST-интерфейса:

• Определение ресурса (URI в HTTP) - независимо от операции используется один и тот же URI.
• Изменение представления - используйте методы, заголовки и тело.
• Самодостаточное сообщение об ошибке (код состояния в HTTP) - используйте коды состояния и не изобретайте велосипед.
• HATEOAS (HTML интерфейс для HTTP) - ваш веб-сервис должен быть доступен через браузер.

Пример REST запроса:

GET /someresources/anId

PUT /someresources/anId
{"anotherdata": "another value"}

REST ориентирован на предоставление данных. Он снижает связанность между клиентом и сервером и часто используется для публичных API. REST использует обобщенный и унифицированный метод предоставления ресурсов через URI, представление через заголовки, и действия с помощью методов, таких как GET, POST, PUT, DELETE и PATCH. Не имея состояния, REST хорошо подходит для горизонтального масштабирования и партицирования.

Disadvantage(s): REST

• Учитывая, что REST ориентирован на предоставление данных, этот подход может не подойти, если ресурсы не достаточно организовоны или их можно получить в виде простой иерархии. Например, возвращение всех обновленных за последних час записей, соответствующих определенному набору событий не так просто представить в виде пути. Скорее всего, в таком случае реализация будет включать сочетание пути URI, параметров запросы и, возможно, тело запроса.
• REST обычно полагается на несколько методов (GET, POST, PUT, DELETE и PATCH), что не всегда может подходить для вашего сценария использования. Например, нет определенного метода для представления перемещения документов с истекшим сроком в архивную папку.
• Получение сложных ресурсов с вложенными иерархиями требует нескольких повторных запросов между клиентов и сервером, например, получение контента записи в блоге и комментариев к этой записи. Для мобильных приложений, которые функционируют в условиях переменного качества сети, эти повторные запросы являюется крайне нежелательными.
• С течением времени, больше полей может добавляться в ответ API, и более старые клиенты будут получать все новые поля, даже те, которые не нужны. В результате, увеличивается размер пересылаемых данных, что приводит к увеличению задержки передачи данных.

RPC and REST calls comparison

Действие	RPC	REST
Регистрация	POST /signup	POST /persons
Удаление пользователя	POST /resign { "personid": "1234" }	DELETE /persons/1234
Получение пользователя (person)	GET /readPerson?personid=1234	GET /persons/1234
Получения списка элементов (item) пользователя	GET /readUsersItemsList?personid=1234	GET /persons/1234/items
Добавления элемента в список пользователя	POST /addItemToUsersItemsList { "personid": "1234"; "itemid": "456" }	POST /persons/1234/items { "itemid": "456" }
Обновления элемента	POST /modifyItem { "itemid": "456"; "key": "value" }	PUT /items/456 { "key": "value" }
Удаление элемента	POST /removeItem { "itemid": "456" }	DELETE /items/456

Source: Do you really know why you prefer REST over RPC

Source(s) and further reading: REST and RPC

• Do you really know why you prefer REST over RPC
• When are RPC-ish approaches more appropriate than REST?
• REST vs JSON-RPC
• Debunking the myths of RPC and REST
• What are the drawbacks of using REST
• Crack the system design interview
• Thrift
• Why REST for internal use and not RPC

Security

Эта секция нуждается в дополнении. contributing!

Обеспечение безопасноcти - это обширная тема. Если у вас нет значительного опыта в безопасности, либо вы не подаётесь на вакансию, которая требует знаний по безопасности, возможно вам будет достаточно основ:

• Шифруйте данные во время передачи и при хранении
• Очищайте входные данные пользователи и любые параметры, которые доступны пользователю для избежания межсайтового скриптинга и внедрения SQL-кода.
• Используйте параметризуемые запросы для предотвращения внедрения SQL-кода
• Используйте принцип минимальных привилегий

Source(s) and further reading

• API security checklist
• Security guide for developers
• OWASP top ten

Appendix

Вас иногда могут попросить сделать оценку по времени "на салфетке". Например, определить, сколько времени понадобится для генерации 100 миниатюр изображений с жесткого диска, или сколько памяти потребует структура данных. Степеней двойки и Время выполнения задач, которые должен знать любой программист могут в этом помочь.

Powers of two table

Степень           Точное значение   Приблизительное значение    Байты
---------------------------------------------------------------------
7                             128
8                             256
10                           1024   1 тысяча                    1 KB
16                         65,536                               64 KB
20                      1,048,576   1 миллион                   1 MB
30                  1,073,741,824   1 миллиард                  1 GB
32                  4,294,967,296                               4 GB
40              1,099,511,627,776   1 триллион                  1 TB

Source(s) and further reading

• Powers of two

Latency numbers every programmer should know

Время выполнения
--------------------------
Обращение к кэшу первого уровня (L1)                                  0.5 ns
Использование альтернативной ветки                                    5   ns
Обращение к кэшу первого уровня (L2)                                  7   ns                      14x L1 кэша
Блокировка/снятие блокировки (mutex)                                 25   ns
Обращение к основной памяти                                         100   ns                      20x L2 кэша, 200x L1 кэша
Сжатие 1 КB с помощью Zippy                                      10,000   ns       10 us
Отправить 1 KB по сети 1 Gbps                                    10,000   ns       10 us
Считать 4 KB случайно с SSD*                                    150,000   ns      150 us          ~1GB/sec SSD
Считать 1 MB последовательно из памяти                          250,000   ns      250 us
Полный обход внутри дата-центра                                 500,000   ns      500 us
Считать 1 MB последовательно с SSD*                           1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X памяти
Поиск на диске                                               10,000,000   ns   10,000 us   10 ms  20x полного обхода дата-центра
Считать 1 MB последовательно по сети 1 Gbps                  10,000,000   ns   10,000 us   10 ms  40x памяти, 10X SSD
Считать 1 MB послеодовательно с диска                        30,000,000   ns   30,000 us   30 ms 120x памяти, 30X SSD
Послать пакет данных Калифорния->Нидерланды->Калифорния     150,000,000   ns  150,000 us  150 ms

Заметки
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Некоторые значения на основе данных выше

• Последовательное чтение с диска - скорость 30 MB/s
• Последовательное чтение из канала 1 Gbps сети Ethernet - скорость 100 MB/s
• Последовательное чтение с SSD - скорость 1 GB/s
• Последовательное чтение из основной памяти - скоростью 4 GB/s
• Количество полных обходов вокруг земного шара в секунду - 6-7
• Количество полных обходов внутри дата-центра в секунду - 2,000

Latency numbers visualized

Source(s) and further reading

• Latency numbers every programmer should know - 1
• Latency numbers every programmer should know - 2
• Designs, lessons, and advice from building large distributed systems
• Software Engineering Advice from Building Large-Scale Distributed Systems

Additional system design interview questions

Распространенные задачи на интервью по проектированию систем со ссылками на решение.

Задача	Ссылки
Design a file sync service like Dropbox	youtube.com
Design a search engine like Google	queue.acm.org stackexchange.com ardendertat.com stanford.edu
Design a scalable web crawler like Google	quora.com
Design Google docs	code.google.com neil.fraser.name
Design a key-value store like Redis	slideshare.net
Design a cache system like Memcached	slideshare.net
Design a recommendation system like Amazon's	hulu.com ijcai13.org
Design a tinyurl system like Bitly	n00tc0d3r.blogspot.com
Design a chat app like WhatsApp	highscalability.com
Design a picture sharing system like Instagram	highscalability.com highscalability.com
Design the Facebook news feed function	quora.com quora.com slideshare.net
Design the Facebook timeline function	facebook.com highscalability.com
Design the Facebook chat function	erlang-factory.com facebook.com
Design a graph search function like Facebook's	facebook.com facebook.com facebook.com
Design a content delivery network like CloudFlare	figshare.com
Design a trending topic system like Twitter's	michael-noll.com snikolov .wordpress.com
Design a random ID generation system	blog.twitter.com github.com
Return the top k requests during a time interval	cs.ucsb.edu wpi.edu
Design a system that serves data from multiple data centers	highscalability.com
Design an online multiplayer card game	indieflashblog.com buildnewgames.com
Design a garbage collection system	stuffwithstuff.com washington.edu
Design an API rate limiter	https://stripe.com/blog/
Add a system design question	Contribute

Real world architectures

Статья о том, как спроектированы действующие системы.

Источник: Twitter timelines at scale

*Не вдавайтесь в мельчайшие подробности, вместо этого:

• Определите основные принципы, общие технологии и шаблоны, которые встречаются в этих статьях
• Изучите, какие проблемы решаются каждым компонентом, где это работает, а где нет
• Обратите внимание секции, описывающие полученный опыт и работу над ошибками

Тип	Система	Ссылки
Обработка данных	MapReduce - распределённая обработка данных от Google	research.google.com
Обработка данных	Spark - распределённая обработка данных от Databricks	slideshare.net
Обработка данных	Storm - распределённая обработка данных от Twitter	slideshare.net
Хранилище данных	Bigtable - распределённая колоночная база данных от Google	harvard.edu
Хранилище данных	HBase - Реализация Bigtable с открытым исходным кодом	slideshare.net
Хранилище данных	Cassandra - распределённая колоночная база данных от Facebook	slideshare.net
Хранилище данных	DynamoDB - Документно-ориенитрованная база данных от Amazon	harvard.edu
Хранилище данных	MongoDB - Документно-ориенитрованная база данных	slideshare.net
Хранилище данных	Spanner - Глобально-распределённая база данных от Google	research.google.com
Хранилище данных	Memcached - распределённый кэш, хранящийся в памяти	slideshare.net
Хранилище данных	Redis - Распеределенная система кэширавния с возможностью сохранения и типами данных	slideshare.net
Файловая система	Google File System (GFS) - распределённая файловая система	research.google.com
Файловая система	Hadoop File System (HDFS) - Реализация GFS с открытым исходным кодом	apache.org
Другое	Chubby - Система блокировки для слабосвязанных распределённых систем от Google	research.google.com
Другое	Dapper - Система отслеживания операций в распределённых системах	research.google.com
Другое	Kafka - Очередь сообщений Pub/sub от LinkedIn	slideshare.net
Другое	Zookeeper - Централизованная инфраструктура и сервисы для синхронизации распределённых систем	slideshare.net
	Добавьте архитектуру	Contribute

Company architectures

Компания	Ссылки
Amazon	Amazon architecture
Cinchcast	Producing 1,500 hours of audio every day
DataSift	Realtime datamining At 120,000 tweets per second
DropBox	How we've scaled Dropbox
ESPN	Operating At 100,000 duh nuh nuhs per second
Google	Google architecture
Instagram	14 million users, terabytes of photos What powers Instagram
Justin.tv	Justin.Tv's live video broadcasting architecture
Facebook	Scaling memcached at Facebook TAO: Facebook’s distributed data store for the social graph Facebook’s photo storage How Facebook Live Streams To 800,000 Simultaneous Viewers
Flickr	Flickr architecture
Mailbox	From 0 to one million users in 6 weeks
Netflix	A 360 Degree View Of The Entire Netflix Stack Netflix: What Happens When You Press Play?
Pinterest	From 0 To 10s of billions of page views a month 18 million visitors, 10x growth, 12 employees
Playfish	50 million monthly users and growing
PlentyOfFish	PlentyOfFish architecture
Salesforce	How they handle 1.3 billion transactions a day
Stack Overflow	Stack Overflow architecture
TripAdvisor	40M visitors, 200M dynamic page views, 30TB data
Tumblr	15 billion page views a month
Twitter	Making Twitter 10000 percent faster Storing 250 million tweets a day using MySQL 150M active users, 300K QPS, a 22 MB/S firehose Timelines at scale Big and small data at Twitter Operations at Twitter: scaling beyond 100 million users How Twitter Handles 3,000 Images Per Second
Uber	How Uber scales their real-time market platform Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories
WhatsApp	The WhatsApp architecture Facebook bought for $19 billion
YouTube	YouTube scalability YouTube architecture

Company engineering blogs

Вопросы могут быть связаны с архитектурой компаний, в которые вы собеседуетесь.

• Airbnb Engineering
• Atlassian Developers
• AWS Blog
• Bitly Engineering Blog
• Box Blogs
• Cloudera Developer Blog
• Dropbox Tech Blog
• Engineering at Quora
• Ebay Tech Blog
• Evernote Tech Blog
• Etsy Code as Craft
• Facebook Engineering
• Flickr Code
• Foursquare Engineering Blog
• GitHub Engineering Blog
• Google Research Blog
• Groupon Engineering Blog
• Heroku Engineering Blog
• Hubspot Engineering Blog
• High Scalability
• Instagram Engineering
• Intel Software Blog
• Jane Street Tech Blog
• LinkedIn Engineering
• Microsoft Engineering
• Microsoft Python Engineering
• Netflix Tech Blog
• Paypal Developer Blog
• Pinterest Engineering Blog
• Quora Engineering
• Reddit Blog
• Salesforce Engineering Blog
• Slack Engineering Blog
• Spotify Labs
• Twilio Engineering Blog
• Twitter Engineering
• Uber Engineering Blog
• Yahoo Engineering Blog
• Yelp Engineering Blog
• Zynga Engineering Blog

Source(s) and further reading

Хотите добавить блог? Во избежание дублирования, добавьте его в этот репозиторий:

• kilimchoi/engineering-blogs

Under development

Заинтересованы в добавлении раздела или в завершении того, что уже в процессе? Содействуйте!!

• распределённые вычисления с MapReduce
• Согласованное хеширование
• Scatter gather
• Содействие

Credits

Источники указаны в самом документе.

Особая благодарность:

• Hired in tech
• Cracking the coding interview
• High scalability
• checkcheckzz/system-design-interview
• shashank88/system_design
• mmcgrana/services-engineering
• System design cheat sheet
• A distributed systems reading list
• Cracking the system design interview

Contact info

Сообщайте мне, если вы хотите обсудить любые проблемы, вопросы или комментарии к этому документу.

Моя контактная информация доступна здесь: GitHub page.

License

I am providing code and resources in this repository to you under an open source license. Because this is my personal repository, the license you receive to my code and resources is from me and not my employer (Facebook).

Copyright 2017 Donne Martin

Creative Commons Attribution 4.0 International License (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/