diff --git a/README-ru.md b/README-ru.md
new file mode 100644
index 00000000..c01c2061
--- /dev/null
+++ b/README-ru.md
@@ -0,0 +1,3365 @@
+[English](README.md) | [日本語](README-ja.md) | **[Русский](README-ru.md)** | [简体中文](README-zh-Hans.md) | [繁體中文](README-zh-TW.md)
+
+
+# Пособие по проектированию систем
+
+
+
+
+
+
+
+
+## Мотивация
+
+> Узнайте, как проектировать крупномасштабные системы.
+>
+> Подготовьтесь к собеседованию по проектированию системы.
+
+
+
+### Научитесь проектировать крупномасштабные системы
+
+Умение проектировать масштабируемые системы поможет вам стать лучшим инженером.
+
+Проектирование систем - это широкая тема. В сети есть **огромное количество ресурсов** по принципам проектирования систем.
+
+Этот репозиторий представляет собой **организованную коллекцию** ресурсов, которые помогут вам научиться создавать системы на большом масштабе.
+
+
+
+### Учитесь у сообщества по разработке ПО с открытым исходным кодом
+
+Это постоянно обновляемый проект с открытым исходным кодом.
+
+[Contributions](#contributing) очень приветствуются!
+
+
+
+### Подготовка к собеседованию по проектированию системы
+
+В дополнение к интервью по написанию кода, проектирование систем является **обязательным компонентом процесса технического интервью** во многих технологических компаниях.
+
+**Практикуйте общие вопросы по проектированию систем** и **сравнивайте** свои результаты с **примерами решений**: обсуждения, код и диаграммы.
+
+Дополнительные темы для подготовки к собеседованию:
+
+* [Study guide](#study-guide)
+* [How to approach a system design interview question](#how-to-approach-a-system-design-interview-question)
+* [System design interview questions, **with solutions**](#system-design-interview-questions-with-solutions)
+* [Object-oriented design interview questions, **with solutions**](#object-oriented-design-interview-questions-with-solutions)
+* [Additional system design interview questions](#additional-system-design-interview-questions)
+
+
+
+## Anki flashcards
+
+
+
+
+
+
+Предоставленные [карточки Anki](https://apps.ankiweb.net/) могут быть использованы для повторения и запоминания ключевых концепций проектирования систем.
+
+* [System design deck](https://github.com/donnemartin/system-design-primer/tree/master/resources/flash_cards/System%20Design.apkg)
+* [System design exercises deck](https://github.com/donnemartin/system-design-primer/tree/master/resources/flash_cards/System%20Design%20Exercises.apkg)
+* [Object oriented design exercises deck](https://github.com/donnemartin/system-design-primer/tree/master/resources/flash_cards/OO%20Design.apkg)
+
+Отлично подходят для использования на ходу.
+
+
+
+### Coding Resource: Interactive Coding Challenges
+
+Ищете ресурсы для подготовки к [**Coding Interview**](https://github.com/donnemartin/interactive-coding-challenges)?
+
+
+
+
+
+
+Посмотрите другой репозиторий [**Interactive Coding Challenges**](https://github.com/donnemartin/interactive-coding-challenges), который тоже содержит колоду карт Anki:
+
+* [Coding deck](https://github.com/donnemartin/interactive-coding-challenges/tree/master/anki_cards/Coding.apkg)
+
+
+
+## Содействие
+
+> Учитесь у сообщества.
+
+Не стесняйтесь отправлять запросы на:
+
+* Исправление ошибок
+* Улучшение разделов
+* Добавление новых разделов
+* [Перевод](https://github.com/donnemartin/system-design-primer/issues/28)
+
+Контент, который нуждается в некоторой полировке, помещается в раздел [В разработке](#under-development).
+
+Ознакомьтесь с [Принципами Содействия](CONTRIBUTING.md).
+
+
+
+## Index of system design topics
+
+> Обобщение различных тем по проектирования систем, включая преимущества и недостатки. **Любое решение требует уступок**.
+>
+> Каждый раздел содержит ссылки на более подробное описание.
+
+
+
+
+
+
+* [System design topics: start here](#system-design-topics-start-here)
+ * [Step 1: Review the scalability video lecture](#step-1-review-the-scalability-video-lecture)
+ * [Step 2: Review the scalability article](#step-2-review-the-scalability-article)
+ * [Next steps](#next-steps)
+* [Performance vs scalability](#performance-vs-scalability)
+* [Latency vs throughput](#latency-vs-throughput)
+* [Availability vs consistency](#availability-vs-consistency)
+ * [CAP theorem](#cap-theorem)
+ * [CP - consistency and partition tolerance](#cp---consistency-and-partition-tolerance)
+ * [AP - availability and partition tolerance](#ap---availability-and-partition-tolerance)
+* [Consistency patterns](#consistency-patterns)
+ * [Weak consistency](#weak-consistency)
+ * [Eventual consistency](#eventual-consistency)
+ * [Strong consistency](#strong-consistency)
+* [Availability patterns](#availability-patterns)
+ * [Fail-over](#fail-over)
+ * [Replication](#replication)
+ * [Availability in numbers](#availability-in-numbers)
+* [Domain name system](#domain-name-system)
+* [Content delivery network](#content-delivery-network)
+ * [Push CDNs](#push-cdns)
+ * [Pull CDNs](#pull-cdns)
+* [Load balancer](#load-balancer)
+ * [Active-passive](#active-passive)
+ * [Active-active](#active-active)
+ * [Layer 4 load balancing](#layer-4-load-balancing)
+ * [Layer 7 load balancing](#layer-7-load-balancing)
+ * [Horizontal scaling](#horizontal-scaling)
+* [Reverse proxy (web server)](#reverse-proxy-web-server)
+ * [Load balancer vs reverse proxy](#load-balancer-vs-reverse-proxy)
+* [Application layer](#application-layer)
+ * [Microservices](#microservices)
+ * [Service discovery](#service-discovery)
+* [Database](#database)
+ * [Relational database management system (RDBMS)](#relational-database-management-system-rdbms)
+ * [Master-slave replication](#master-slave-replication)
+ * [Master-master replication](#master-master-replication)
+ * [Federation](#federation)
+ * [Sharding](#sharding)
+ * [Denormalization](#denormalization)
+ * [SQL tuning](#sql-tuning)
+ * [NoSQL](#nosql)
+ * [Key-value store](#key-value-store)
+ * [Document store](#document-store)
+ * [Wide column store](#wide-column-store)
+ * [Graph Database](#graph-database)
+ * [SQL or NoSQL](#sql-or-nosql)
+* [Cache](#cache)
+ * [Client caching](#client-caching)
+ * [CDN caching](#cdn-caching)
+ * [Web server caching](#web-server-caching)
+ * [Database caching](#database-caching)
+ * [Application caching](#application-caching)
+ * [Caching at the database query level](#caching-at-the-database-query-level)
+ * [Caching at the object level](#caching-at-the-object-level)
+ * [When to update the cache](#when-to-update-the-cache)
+ * [Cache-aside](#cache-aside)
+ * [Write-through](#write-through)
+ * [Write-behind (write-back)](#write-behind-write-back)
+ * [Refresh-ahead](#refresh-ahead)
+* [Asynchronism](#asynchronism)
+ * [Message queues](#message-queues)
+ * [Task queues](#task-queues)
+ * [Back pressure](#back-pressure)
+* [Communication](#communication)
+ * [Transmission control protocol (TCP)](#transmission-control-protocol-tcp)
+ * [User datagram protocol (UDP)](#user-datagram-protocol-udp)
+ * [Remote procedure call (RPC)](#remote-procedure-call-rpc)
+ * [Representational state transfer (REST)](#representational-state-transfer-rest)
+* [Security](#security)
+* [Appendix](#appendix)
+ * [Powers of two table](#powers-of-two-table)
+ * [Latency numbers every programmer should know](#latency-numbers-every-programmer-should-know)
+ * [Additional system design interview questions](#additional-system-design-interview-questions)
+ * [Real world architectures](#real-world-architectures)
+ * [Company architectures](#company-architectures)
+ * [Company engineering blogs](#company-engineering-blogs)
+* [Under development](#under-development)
+* [Credits](#credits)
+* [Contact info](#contact-info)
+* [License](#license)
+
+
+
+## Study guide
+
+> Предлагаемые темы для повторения в зависимости от того, сколько у вас есть времени для подготовки к интервью (мало, средне, много)
+
+![Imgur](http://i.imgur.com/OfVllex.png)
+
+**Вопрос: Надо ли мне знать все из этого документа для интервью?**
+
+**Ответ: Нет, не обязательно**.
+
+То, что вас будут спрашивать на интервью, зависит от:
+
+* Вашего опыта - сколько времени и чем вы занимались
+* Должности, на которую вы собеседуетесь
+* Компания, в которую вы собеседуетесь
+* Удача
+
+Ожидается, что более опытные кандидаты в общем случае знают больше о проектировании систем, а архитекторы и руководители комманд знают больше, чем индивидуальные разработчики. Топовые IT компании скорее всего будут проводить один или более этапов собеседования по проектированию систем.
+
+Начинайте широко, и углубляейтесь в некоторые области. Это поможет узнать больше о различных темах по проектированию систем. Корректируйте ваш план в зависомости от того, сколько у вас есть времени, какой у вас опыт, на какую должность вы собеседуетесь и в какие компании.
+
+* **Короткий срок** - настраиватесь на **широту** покрытия тем. Тренируйтесь отвечать на **некоторые** вопросы.
+* **Средний срок** - настраиватесь на **широту** и **немного глубины** покрытия тем. Тренируйтесь отвечать на **многие** вопросы.
+* **Длительный срок** - настраиватесь на **широту** и **больше глубины** покрытия тем. Тренируйтесь отвечать на **большинство** вопросов.
+
+| | Малый срок | Средний срок | Длительный срок |
+|---|---|---|---|
+| Читайте [System design topics](#index-of-system-design-topics), чтобы получить общее понимание, как работают системы | :+1: | :+1: | :+1: |
+| Почитайте несколько статей из блогов компаний, в который вы собеседуетесь [Company engineering blogs](#company-engineering-blogs) | :+1: | :+1: | :+1: |
+| Посмотрите несколько [Real world architectures](#real-world-architectures) | :+1: | :+1: | :+1: |
+| [How to approach a system design interview question](#how-to-approach-a-system-design-interview-question) | :+1: | :+1: | :+1: |
+| [System design interview questions with solutions](#system-design-interview-questions-with-solutions) | Немного | Много | Большинство |
+| [Object-oriented design interview questions with solutions](#object-oriented-design-interview-questions-with-solutions) | Немного | Много | Большинство |
+| [Additional system design interview questions](#additional-system-design-interview-questions) | Немного | Много | Большинство |
+
+
+
+## How to approach a system design interview question
+
+> Как отвечать на вопросы на интерьвю по проектированию систем
+
+Это интервью является **открытой беседой**. Ожидается, что вы возьмете инициативу по его ведению на себя.
+
+Изучите раздел [System design interview questions with solutions](#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](solutions/system_design/pastebin/README.md), обсудите следующие моменты:
+
+* Генерация и хранения хэша оригинального URL
+ * [MD5](solutions/system_design/pastebin/README.md) и [Base62](solutions/system_design/pastebin/README.md)
+ * Коллизии хэш-функции
+ * SQL или NoSQL
+ * Схема базы данных
+* Перевод хэшированного URL в оригинальный URL
+ * Поиск в базе данных
+* API и объектно-ориентированное проектирование
+
+
+
+### Step 4: Scale the design
+
+Определите узкие места и разберитесь с ними, учитывая данные ограничения. Например, для решение проблем с масштабируемостью, может ли вам понадобиться что-то из:
+
+* Балансировщик нагрузки
+* Горизонтальное машстабирование
+* Кэширование
+* Шардинг (sharding) базы данных
+
+Обсудите потенциальные варианты и уступки. Разберитесь с узкими местами используя [principles of scalable system design](#index-of-system-design-topics).
+
+
+
+### Back-of-the-envelope calculations
+
+Вас могу спросить сделать оценку решения по некоторые параметрам. Некоторые разделы [Appendix](#appendix) могут с этим помочь:
+
+* [Use back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)
+* [Powers of two table](#powers-of-two-table)
+* [Latency numbers every programmer should know](#latency-numbers-every-programmer-should-know)
+
+
+
+### Source(s) and further reading
+
+Посмотрите следующие ссылки, чтобы понять, что можно ожидать (внешние ссылки без перевода):
+
+* [Use back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)
+* [Powers of two table](#powers-of-two-table)
+* [Latency numbers every programmer should know](#latency-numbers-every-programmer-should-know)
+
+
+
+## System design interview questions with solutions
+
+> Распространенные задачи с обсуждением, кодом и диаграммами.
+>
+> Решение находятся в директории `solutions/`.
+
+| Задача на проектирование | |
+|---|---|
+| Pastebin.com (или Bit.ly) | [Решение](solutions/system_design/pastebin/README.md) |
+| Лента и поиск в Twitter (или Facebook) | [Решение](solutions/system_design/twitter/README.md) |
+| Веб-сканер | [Решение](solutions/system_design/web_crawler/README.md) |
+| Система управление личными финансами Mint.com | [Решение](solutions/system_design/mint/README.md) |
+| Структура данных для социальной сети | [Решение](solutions/system_design/social_graph/README.md) |
+| Хранилище типа ключ-значение для поисковика | [Решение](solutions/system_design/query_cache/README.md) |
+| Рейтинг продаж по категориям в Amazon | [Решение](solutions/system_design/sales_rank/README.md) |
+| Система, которая масштабируется до миллиона пользователей на AWS | [Решение](solutions/system_design/scaling_aws/README.md) |
+| Добавьте задачу | [Решение](#contributing) |
+
+
+
+### Design Pastebin.com (or Bit.ly)
+
+[Требования и решение](solutions/system_design/pastebin/README.md)
+
+![Imgur](http://i.imgur.com/4edXG0T.png)
+
+
+
+### Design the Twitter timeline and search (or Facebook feed and search)
+
+[Требования и решение](solutions/system_design/twitter/README.md)
+
+![Imgur](http://i.imgur.com/jrUBAF7.png)
+
+
+
+### Design a web crawler
+
+[Требования и решение](solutions/system_design/web_crawler/README.md)
+
+![Imgur](http://i.imgur.com/bWxPtQA.png)
+
+
+
+### Design Mint.com
+
+[Требования и решение](solutions/system_design/mint/README.md)
+
+![Imgur](http://i.imgur.com/V5q57vU.png)
+
+
+
+### Design the data structures for a social network
+
+[Требования и решение](solutions/system_design/social_graph/README.md)
+
+![Imgur](http://i.imgur.com/cdCv5g7.png)
+
+
+
+### Design a key-value store for a search engine
+
+[Требования и решение](solutions/system_design/query_cache/README.md)
+
+![Imgur](http://i.imgur.com/4j99mhe.png)
+
+
+
+### Design Amazon's sales ranking by category feature
+
+[Требование и решение](solutions/system_design/sales_rank/README.md)
+
+![Imgur](http://i.imgur.com/MzExP06.png)
+
+
+
+### Design a system that scales to millions of users on AWS
+
+[Требования и решение](solutions/system_design/scaling_aws/README.md)
+
+![Imgur](http://i.imgur.com/jj3A5N8.png)
+
+
+
+## Object-oriented design interview questions with solutions
+
+> Распространенные задачи с обсуждением, кодом и диаграммами.
+>
+> Решение находятся в директории `solutions/`.
+
+>**Внимание, этот раздел находится в стадии разработки**
+
+| Задачи на проектировние | |
+|---|---|
+| Хэш таблица | [Решение](solutions/object_oriented_design/hash_table/hash_map.ipynb) |
+| Кэширование с удалением давно используемых (Least recently used - LRU) | [Решение](solutions/object_oriented_design/lru_cache/lru_cache.ipynb) |
+| Центр обработки звонков | [Решение](solutions/object_oriented_design/call_center/call_center.ipynb) |
+| Колода карт | [Решение](solutions/object_oriented_design/deck_of_cards/deck_of_cards.ipynb) |
+| Парковка | [Решение](solutions/object_oriented_design/parking_lot/parking_lot.ipynb) |
+| Чат сервер | [Решение](solutions/object_oriented_design/online_chat/online_chat.ipynb) |
+| Циклический массив | [Contribute](#contributing) |
+| Добавьте задачу | [Contribute](#contributing) |
+
+
+
+## System design topics: start here
+
+Только начинайте изучать проектирование систем?
+
+Для начала, вам понадобится понимание базовых принципов, как они используются, их преимущества и недостатки.
+
+
+
+### Step 1: Review the scalability video lecture
+
+[Лекция по масштабированию в Гарварде](https://www.youtube.com/watch?v=-W9F__D3oY4)
+
+* Темы:
+ * Вертикальное масштабирование
+ * Горизонтальное масштабирование
+ * Кэширование
+ * Балансировка нагрузки
+ * Репликация баз данных
+ * Секцирование (Partitioning) баз данных
+
+
+
+### Step 2: Review the scalability article
+
+[Масштабирование](http://www.lecloud.net/tagged/scalability/chrono)
+
+* Темы:
+ * [Клонирование](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
+ * [Базы данных](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
+ * [Кэши](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
+ * [Асинхронность](http://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)
+
+
+
+### Next steps
+
+Далее, изучим уступки в общем виде:
+
+* **Производительность** и **масштабирование**
+* **Задержка** и **пропускная способность**
+* **Доступность** и **согласованность данных**
+
+Помните, что **везде необходимы уступки**.
+
+Далее, изучем более детально DNS, CDN, балансировщики нагрузки и другие темы.
+
+
+
+## Performance vs scalability
+
+Сервис считается **масштабируемым**, если его **производительность** растет пропорционально добавленным ресурсам. Обычно под увеличением производительности подразумевают увеличение количества обрабатываемых единиц работы. Однако, это может быть и обработка более крупных единиц работы, как, например, при росте объема данных.1
+
+Иначе говоря:
+
+* если у вас проблемы с **производительностью**, ваша система медленная для одного пользователя;
+* если у вас проблемы с **масштабируемостью**, ваша системы быстрая для одного пользователя, но становится медленной под большой нагрузкой.
+
+
+
+### Source(s) and further reading
+
+* [A word on scalability](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
+* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
+
+
+
+## Latency vs throughput
+
+**Задержка** - это время, необходимое для выполнения действия или достижения некоторого результата.
+
+**Пропускная способность** - это количество такие действий или результататов в единицу времени.
+
+Обычно следует стремиться к **максимальной пропускной способности**, при этом сохраняя **задержку приемлимой**.
+
+
+
+### Source(s) and further reading
+
+* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/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](#eventual-consistency).
+
+
+
+### Source(s) and further reading
+
+* [CAP theorem revisited](http://robertgreiner.com/2014/08/cap-theorem-revisited/)
+* [A plain english introduction to CAP theorem](http://ksat.me/a-plain-english-introduction-to-cap-theorem)
+* [CAP FAQ](https://github.com/henryr/cap-faq)
+
+
+
+## Consistency patterns
+
+В распределенной системе можете существовать несколько копий одних и тех же данных. Для достижения согласованности данных, получаемых клиенстким приложением, существует несколько подходов синхронизации этих копий.
+
+
+
+### Weak consistency
+
+После операции записи данных, операция чтения может увидеть эти данные, а может и не увидеть. Используется подход, при котором можно сделать как можно лучше, но с учетом данной ситуации.
+
+Этот подход используеются в таких системах, как memcached. Слабая согласованность применяется в таких системах как VoIP, видео чаты и игры реального времени на несколько игроков.
+
+
+
+### Eventual consistency
+
+После операции записи данных, операция чтения в конечном счете увидит эти данные (обычно в течение нескольких миллисекунд). Данных в таком случае реплицируются асинхронно.
+
+Такой подход используется в таких системах, как DNS и электронная почта. Согласованность в конечном счете хорошо подходит для систем с высокой доступностью.
+
+
+
+### Strong consistency
+
+После операции записи данных, операция чтения увидит эти данны. Данные реплицируются синхронно.
+
+Такой подход используеются в файловых системаях и реляционных БД. Сильная согласованность хорошо подходит для систем, где требуются транзакции.
+
+
+
+### Source(s) and further reading
+
+* [Transactions across data centers](http://snarfed.org/transactions_across_datacenters_io.html)
+
+
+
+## Availability patterns
+
+Для обеспечения высокой доступности существует два основных паттерна: **отказоустойчивость** и **репликация**.
+
+
+
+### Fail-over
+
+
+
+#### Active-passive
+
+В таком режиме, активный и пассивны сервер, находящийся в режиме ожидание, обмениваются специальными сообщениями - heartbeats. Если такой сообщение не получается, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.
+
+Время простоя определяется в каком состоянии находится пассивный сервер:
+
+* горячее (hot) ожидание - сервер уже работает
+* холодное (cold) ожидание - сервер должен быть запущен.
+
+Только активный сервер может обрабатывать клиентские запросы.
+
+
+
+#### Active-active
+
+В таком режиме, оба сервера обрабатывают клиентские запросы, распределяют нагрузку между собой.
+
+Если сервера имеют общий доступ, то публичные IP адреса обоих серверов должны быть зарегистрированы в DNS. Если сервера находятся во внутренней сети, то клиентское приложение знать про оба сервера.
+
+Режим "активный-активный" также известен как "ведущий-ведущий".
+
+
+
+### Disadvantage(s): failover
+
+* Отказоустойчивость делает систему более сложной и требует большего количества аппаратного обеспечения.
+* Существует вероятность потери данных, если данных не успели реплицироваться во время переключения активного и пассивного серверов.
+
+
+
+### Replication
+
+
+
+#### Master-slave and master-master
+
+Эта тема обсуждается далее в разделе [Database](#database):
+
+* [Master-slave replication](#master-slave-replication)
+* [Master-master 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
+
+TBD
+
+
+
+### Disadvantage(s): DNS
+
+TBD
+
+
+
+### Source(s) and further reading
+
+TBD
+
+
+
+## Content delivery network
+
+TBD
+
+
+
+### Push CDNs
+
+TBD
+
+
+
+### Pull CDNs
+
+TBD
+
+
+
+### Disadvantage(s): CDN
+
+TBD
+
+
+
+### Source(s) and further reading
+
+TBD
+
+
+
+## Load balancer
+
+TBD
+
+
+
+### Layer 4 load balancing
+
+TBD
+
+
+
+### Layer 7 load balancing
+
+TBD
+
+
+
+### Horizontal scaling
+
+TBD
+
+
+
+#### Disadvantage(s): horizontal scaling
+
+TBD
+
+
+
+### Disadvantage(s): load balancer
+
+TBD
+
+
+
+### Source(s) and further reading
+
+TBD
+
+
+
+## Reverse proxy (web server)
+
+TBD
+
+
+
+### Load balancer vs reverse proxy
+
+TBD
+
+
+
+### Disadvantage(s): reverse proxy
+
+TBD
+
+
+
+### Source(s) and further reading
+
+TBD
+
+
+
+## Application layer
+
+TBD
+
+
+
+### Microservices
+
+TBD
+
+
+
+### Service Discovery
+
+TBD
+
+
+
+### Disadvantage(s): application layer
+
+TBD
+
+
+
+### Source(s) and further reading
+
+TBD
+
+
+
+## Database
+
+TBD
+
+
+
+### Relational database management system (RDBMS)
+
+TBD
+
+
+
+#### Master-slave replication
+
+TBD
+
+
+
+##### Disadvantage(s): master-slave replication
+
+TBD
+
+
+
+#### Master-master replication
+
+TBD
+
+
+
+##### Disadvantage(s): master-master replication
+
+TBD
+
+
+
+##### Disadvantage(s): replication
+
+TBD
+
+
+
+##### Source(s) and further reading: replication
+
+TBD
+
+
+
+#### Federation
+
+TBD
+
+
+
+##### Disadvantage(s): federation
+
+TBD
+
+
+
+##### Source(s) and further reading: federation
+
+TBD
+
+
+
+#### Sharding
+
+TBD
+
+
+
+##### Disadvantage(s): sharding
+
+TBD
+
+
+
+##### Source(s) and further reading: sharding
+
+TBD
+
+
+
+#### Denormalization
+
+TBD
+
+
+
+##### Disadvantage(s): denormalization
+
+TBD
+
+
+
+###### Source(s) and further reading: denormalization
+
+TBD
+
+
+
+#### SQL tuning
+
+TBD
+
+
+
+##### Tighten up the schema
+
+TBD
+
+
+
+##### Use good indices
+
+TBD
+
+
+
+##### Avoid expensive joins
+
+TBD
+
+
+
+##### Partition tables
+
+TBD
+
+
+
+##### Tune the query cache
+
+TBD
+
+
+
+##### Source(s) and further reading: SQL tuning
+
+TBD
+
+
+
+### NoSQL
+
+TBD
+
+
+
+#### Key-value store
+
+TBD
+
+
+
+##### Source(s) and further reading: key-value store
+
+TBD
+
+
+
+#### Document store
+
+TBD
+
+
+
+##### Source(s) and further reading: document store
+
+TBD
+
+
+
+#### Wide column store
+
+TBD
+
+
+
+##### Source(s) and further reading: wide column store
+
+TBD
+
+
+
+#### Graph database
+
+TBD
+
+
+
+##### Source(s) and further reading: graph
+
+TBD
+
+
+
+#### Source(s) and further reading: NoSQL
+
+TBD
+
+
+
+### SQL or NoSQL
+
+TBD
+
+
+
+##### Source(s) and further reading: SQL or NoSQL
+
+TBD
+
+
+
+## Cache
+
+TBD
+
+
+
+### Client caching
+
+TBD
+
+
+
+### CDN caching
+
+TBD
+
+
+
+### Web server caching
+
+TBD
+
+
+
+### Database caching
+
+TBD
+
+
+
+### Application caching
+
+TBD
+
+
+
+### Caching at the database query level
+
+TBD
+
+
+
+### Caching at the object level
+
+TBD
+
+
+
+### When to update the cache
+
+TBD
+
+
+
+#### Cache-aside
+
+TBD
+
+
+
+##### Disadvantage(s): cache-aside
+
+TBD
+
+
+
+#### Write-through
+
+TBD
+
+
+
+##### Disadvantage(s): write through
+
+TBD
+
+
+
+#### Write-behind (write-back)
+
+TBD
+
+
+
+##### Disadvantage(s): write-behind
+
+TBD
+
+
+
+#### Refresh-ahead
+
+TBD
+
+
+
+##### Disadvantage(s): refresh-ahead
+
+TBD
+
+
+
+### Disadvantage(s): cache
+
+TBD
+
+
+
+### Source(s) and further reading
+
+TBD
+
+
+
+## Asynchronism
+
+TBD
+
+
+
+### Message queues
+
+TBD
+
+
+
+### Task queues
+
+TBD
+
+
+
+### Back pressure
+
+TBD
+
+
+
+### Disadvantage(s): asynchronism
+
+TBD
+
+
+
+### Source(s) and further reading
+
+TBD
+
+
+
+## Communication
+
+TBD
+
+
+
+### Hypertext transfer protocol (HTTP)
+
+TBD
+
+
+
+#### Source(s) and further reading: HTTP
+
+TBD
+
+
+
+### Transmission control protocol (TCP)
+
+TBD
+
+
+
+### User datagram protocol (UDP)
+
+TBD
+
+
+
+#### Source(s) and further reading: TCP and UDP
+
+TBD
+
+
+
+### Remote procedure call (RPC)
+
+TBD
+
+
+
+#### Disadvantage(s): RPC
+
+TBD
+
+
+
+### Representational state transfer (REST)
+
+TBD
+
+
+
+#### Disadvantage(s): REST
+
+TBD
+
+
+
+### RPC and REST calls comparison
+
+TBD
+
+
+
+#### Source(s) and further reading: REST and RPC
+
+TBD
+
+
+
+## Security
+
+TBD
+
+
+
+### Source(s) and further reading
+
+TBD
+
+
+
+## Appendix
+
+TBD
+
+
+
+### Powers of two table
+
+TBD
+
+
+
+#### Source(s) and further reading
+
+TBD
+
+
+
+### Latency numbers every programmer should know
+
+TBD
+
+
+
+#### Latency numbers visualized
+
+![](https://camo.githubusercontent.com/77f72259e1eb58596b564d1ad823af1853bc60a3/687474703a2f2f692e696d6775722e636f6d2f6b307431652e706e67)
+
+
+
+#### Source(s) and further reading
+
+* [Latency numbers every programmer should know - 1](https://gist.github.com/jboner/2841832)
+* [Latency numbers every programmer should know - 2](https://gist.github.com/hellerbarde/2843375)
+* [Designs, lessons, and advice from building large distributed systems](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf)
+* [Software Engineering Advice from Building Large-Scale Distributed Systems](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf)
+
+
+
+### Additional system design interview questions
+
+> Распространенные задачи на интервью по проектированию систем со ссылками на решение.
+
+| Задача | Ссылки |
+|---|---|
+| Design a file sync service like Dropbox | [youtube.com](https://www.youtube.com/watch?v=PE4gwstWhmc) |
+| Design a search engine like Google | [queue.acm.org](http://queue.acm.org/detail.cfm?id=988407)
[stackexchange.com](http://programmers.stackexchange.com/questions/38324/interview-question-how-would-you-implement-google-search)
[ardendertat.com](http://www.ardendertat.com/2012/01/11/implementing-search-engines/)
[stanford.edu](http://infolab.stanford.edu/~backrub/google.html) |
+| Design a scalable web crawler like Google | [quora.com](https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch) |
+| Design Google docs | [code.google.com](https://code.google.com/p/google-mobwrite/)
[neil.fraser.name](https://neil.fraser.name/writing/sync/) |
+| Design a key-value store like Redis | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |
+| Design a cache system like Memcached | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
+| Design a recommendation system like Amazon's | [hulu.com](https://web.archive.org/web/20170406065247/http://tech.hulu.com/blog/2011/09/19/recommendation-system.html)
[ijcai13.org](http://ijcai13.org/files/tutorial_slides/td3.pdf) |
+| Design a tinyurl system like Bitly | [n00tc0d3r.blogspot.com](http://n00tc0d3r.blogspot.com/) |
+| Design a chat app like WhatsApp | [highscalability.com](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html)
+| Design a picture sharing system like Instagram | [highscalability.com](http://highscalability.com/flickr-architecture)
[highscalability.com](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html) |
+| Design the Facebook news feed function | [quora.com](http://www.quora.com/What-are-best-practices-for-building-something-like-a-News-Feed)
[quora.com](http://www.quora.com/Activity-Streams/What-are-the-scaling-issues-to-keep-in-mind-while-developing-a-social-network-feed)
[slideshare.net](http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture) |
+| Design the Facebook timeline function | [facebook.com](https://www.facebook.com/note.php?note_id=10150468255628920)
[highscalability.com](http://highscalability.com/blog/2012/1/23/facebook-timeline-brought-to-you-by-the-power-of-denormaliza.html) |
+| Design the Facebook chat function | [erlang-factory.com](http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf)
[facebook.com](https://www.facebook.com/note.php?note_id=14218138919&id=9445547199&index=0) |
+| Design a graph search function like Facebook's | [facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-out-the-infrastructure-for-graph-search/10151347573598920)
[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-indexing-and-ranking-in-graph-search/10151361720763920)
[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-the-natural-language-interface-of-graph-search/10151432733048920) |
+| Design a content delivery network like CloudFlare | [figshare.com](https://figshare.com/articles/Globally_distributed_content_delivery/6605972) |
+| Design a trending topic system like Twitter's | [michael-noll.com](http://www.michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in-storm/)
[snikolov .wordpress.com](http://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/) |
+| Design a random ID generation system | [blog.twitter.com](https://blog.twitter.com/2010/announcing-snowflake)
[github.com](https://github.com/twitter/snowflake/) |
+| Return the top k requests during a time interval | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/cs.ucsb.edu/files/docs/reports/2005-23.pdf)
[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
+| Design a system that serves data from multiple data centers | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |
+| Design an online multiplayer card game | [indieflashblog.com](http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html)
[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
+| Design a garbage collection system | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)
[washington.edu](http://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) |
+| Design an API rate limiter | [https://stripe.com/blog/](https://stripe.com/blog/rate-limiters) |
+| Add a system design question | [Contribute](#contributing) |
+
+
+
+### Real world architectures
+
+> Статья о том, как спроектированы действующие системы.
+
+
+
+
+ Источник: Twitter timelines at scale
+
+
+**Не вдавайтесь в мельчайшие подробности, вместо этого:*
+
+* Определите основные принципы, общие технологии и шаблоны, которые встречаются в этих статьях
+* Изучите, какие проблемы решаются каждым компонентом, где это работает, а где нет
+* Обратите внимание секции, описывающие полученный опыт и работу над ошибками
+
+| Тип | Система | Ссылки |
+|---|---|---|
+| Обработка данных | **MapReduce** - Распределенная обработка данных от Google | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/mapreduce-osdi04.pdf) |
+| Обработка данных | **Spark** - Распределенная обработка данных от Databricks | [slideshare.net](http://www.slideshare.net/AGrishchenko/apache-spark-architecture) |
+| Обработка данных | **Storm** - Распределенная обработка данных от Twitter | [slideshare.net](http://www.slideshare.net/previa/storm-16094009) |
+| | | |
+| Хранилище данных | **Bigtable** - Распределенная колоночная база данных от Google | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) |
+| Хранилище данных | **HBase** - Реализация Bigtable с открытым исходным кодом | [slideshare.net](http://www.slideshare.net/alexbaranau/intro-to-hbase) |
+| Хранилище данных | **Cassandra** - Распределенная колоночная база данных от Facebook | [slideshare.net](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666)
+| Хранилище данных | **DynamoDB** - Документно-ориенитрованная база данных от Amazon | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) |
+| Хранилище данных | **MongoDB** - Документно-ориенитрованная база данных | [slideshare.net](http://www.slideshare.net/mdirolf/introduction-to-mongodb) |
+| Хранилище данных | **Spanner** - Глобально-распределенная база данных от Google | [research.google.com](http://research.google.com/archive/spanner-osdi2012.pdf) |
+| Хранилище данных | **Memcached** - Распределенный кэш, хранящийся в памяти | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
+| Хранилище данных | **Redis** - Распеределенная система кэширавния с возможностью сохранения и типами данных | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |
+| | | |
+| Файловая система | **Google File System (GFS)** - Распределенная файловая система | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/gfs-sosp2003.pdf) |
+| Файловая система | **Hadoop File System (HDFS)** - Реализация GFS с открытым исходным кодом | [apache.org](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) |
+| | | |
+| Другое | **Chubby** - Система блокировки для слабосвязанных распределенных систем от Google | [research.google.com](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf) |
+| Другое | **Dapper** - Система отслеживания операций в распределенных системах | [research.google.com](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf)
+| Другое | **Kafka** - Очередь сообщений Pub/sub от LinkedIn | [slideshare.net](http://www.slideshare.net/mumrah/kafka-talk-tri-hug) |
+| Другое | **Zookeeper** - Централизованная инфраструктура и сервисы для синхронизации распределенных систем | [slideshare.net](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) |
+| | Добавьте архитектуру | [Contribute](#contributing) |
+
+
+
+### Company architectures
+
+| Компания | Ссылки |
+|---|---|
+| Amazon | [Amazon architecture](http://highscalability.com/amazon-architecture) |
+| Cinchcast | [Producing 1,500 hours of audio every day](http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html) |
+| DataSift | [Realtime datamining At 120,000 tweets per second](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) |
+| DropBox | [How we've scaled Dropbox](https://www.youtube.com/watch?v=PE4gwstWhmc) |
+| ESPN | [Operating At 100,000 duh nuh nuhs per second](http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html) |
+| Google | [Google architecture](http://highscalability.com/google-architecture) |
+| Instagram | [14 million users, terabytes of photos](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html)
[What powers Instagram](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances) |
+| Justin.tv | [Justin.Tv's live video broadcasting architecture](http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html) |
+| Facebook | [Scaling memcached at Facebook](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/key-value/fb-memcached-nsdi-2013.pdf)
[TAO: Facebook’s distributed data store for the social graph](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/data-store/tao-facebook-distributed-datastore-atc-2013.pdf)
[Facebook’s photo storage](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Beaver.pdf)
[How Facebook Live Streams To 800,000 Simultaneous Viewers](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html) |
+| Flickr | [Flickr architecture](http://highscalability.com/flickr-architecture) |
+| Mailbox | [From 0 to one million users in 6 weeks](http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html) |
+| Netflix | [A 360 Degree View Of The Entire Netflix Stack](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)
[Netflix: What Happens When You Press Play?](http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html) |
+| Pinterest | [From 0 To 10s of billions of page views a month](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html)
[18 million visitors, 10x growth, 12 employees](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) |
+| Playfish | [50 million monthly users and growing](http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html) |
+| PlentyOfFish | [PlentyOfFish architecture](http://highscalability.com/plentyoffish-architecture) |
+| Salesforce | [How they handle 1.3 billion transactions a day](http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html) |
+| Stack Overflow | [Stack Overflow architecture](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) |
+| TripAdvisor | [40M visitors, 200M dynamic page views, 30TB data](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html) |
+| Tumblr | [15 billion page views a month](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) |
+| Twitter | [Making Twitter 10000 percent faster](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster)
[Storing 250 million tweets a day using MySQL](http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html)
[150M active users, 300K QPS, a 22 MB/S firehose](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html)
[Timelines at scale](https://www.infoq.com/presentations/Twitter-Timeline-Scalability)
[Big and small data at Twitter](https://www.youtube.com/watch?v=5cKTP36HVgI)
[Operations at Twitter: scaling beyond 100 million users](https://www.youtube.com/watch?v=z8LU0Cj6BOU)
[How Twitter Handles 3,000 Images Per Second](http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html) |
+| Uber | [How Uber scales their real-time market platform](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html)
[Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) |
+| WhatsApp | [The WhatsApp architecture Facebook bought for $19 billion](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) |
+| YouTube | [YouTube scalability](https://www.youtube.com/watch?v=w5WVu624fY8)
[YouTube architecture](http://highscalability.com/youtube-architecture) |
+
+
+
+### Company engineering blogs
+
+> Вопросы могут быть связаны с архитектурой компаний, в которые вы собеседуетесь.
+
+* [Airbnb Engineering](http://nerds.airbnb.com/)
+* [Atlassian Developers](https://developer.atlassian.com/blog/)
+* [AWS Blog](https://aws.amazon.com/blogs/aws/)
+* [Bitly Engineering Blog](http://word.bitly.com/)
+* [Box Blogs](https://blog.box.com/blog/category/engineering)
+* [Cloudera Developer Blog](http://blog.cloudera.com/)
+* [Dropbox Tech Blog](https://tech.dropbox.com/)
+* [Engineering at Quora](http://engineering.quora.com/)
+* [Ebay Tech Blog](http://www.ebaytechblog.com/)
+* [Evernote Tech Blog](https://blog.evernote.com/tech/)
+* [Etsy Code as Craft](http://codeascraft.com/)
+* [Facebook Engineering](https://www.facebook.com/Engineering)
+* [Flickr Code](http://code.flickr.net/)
+* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
+* [GitHub Engineering Blog](http://githubengineering.com/)
+* [Google Research Blog](http://googleresearch.blogspot.com/)
+* [Groupon Engineering Blog](https://engineering.groupon.com/)
+* [Heroku Engineering Blog](https://engineering.heroku.com/)
+* [Hubspot Engineering Blog](http://product.hubspot.com/blog/topic/engineering)
+* [High Scalability](http://highscalability.com/)
+* [Instagram Engineering](http://instagram-engineering.tumblr.com/)
+* [Intel Software Blog](https://software.intel.com/en-us/blogs/)
+* [Jane Street Tech Blog](https://blogs.janestreet.com/category/ocaml/)
+* [LinkedIn Engineering](http://engineering.linkedin.com/blog)
+* [Microsoft Engineering](https://engineering.microsoft.com/)
+* [Microsoft Python Engineering](https://blogs.msdn.microsoft.com/pythonengineering/)
+* [Netflix Tech Blog](http://techblog.netflix.com/)
+* [Paypal Developer Blog](https://devblog.paypal.com/category/engineering/)
+* [Pinterest Engineering Blog](https://medium.com/@Pinterest_Engineering)
+* [Quora Engineering](https://engineering.quora.com/)
+* [Reddit Blog](http://www.redditblog.com/)
+* [Salesforce Engineering Blog](https://developer.salesforce.com/blogs/engineering/)
+* [Slack Engineering Blog](https://slack.engineering/)
+* [Spotify Labs](https://labs.spotify.com/)
+* [Twilio Engineering Blog](http://www.twilio.com/engineering)
+* [Twitter Engineering](https://blog.twitter.com/engineering/)
+* [Uber Engineering Blog](http://eng.uber.com/)
+* [Yahoo Engineering Blog](http://yahooeng.tumblr.com/)
+* [Yelp Engineering Blog](http://engineeringblog.yelp.com/)
+* [Zynga Engineering Blog](https://www.zynga.com/blogs/engineering)
+
+
+
+#### Source(s) and further reading
+
+Хотите добавить блог? Во избежание дублирования, добавьте его в этот репозиторий:
+
+* [kilimchoi/engineering-blogs](https://github.com/kilimchoi/engineering-blogs)
+
+
+
+## Under development
+
+Заинтересованы в добавлении раздела или в завершении того, что уже в процессе? [Содействуйте!](#contributing)!
+
+* Распределенные вычисления с MapReduce
+* Согласованное хеширование
+* Scatter gather
+* [Содействие](#contributing)
+
+
+
+## Credits
+
+Источники указаны в самом документе.
+
+Особая благодарность:
+
+* [Hired in tech](http://www.hiredintech.com/system-design/the-system-design-process/)
+* [Cracking the coding interview](https://www.amazon.com/dp/0984782850/)
+* [High scalability](http://highscalability.com/)
+* [checkcheckzz/system-design-interview](https://github.com/checkcheckzz/system-design-interview)
+* [shashank88/system_design](https://github.com/shashank88/system_design)
+* [mmcgrana/services-engineering](https://github.com/mmcgrana/services-engineering)
+* [System design cheat sheet](https://gist.github.com/vasanthk/485d1c25737e8e72759f)
+* [A distributed systems reading list](http://dancres.github.io/Pages/)
+* [Cracking the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
+
+
+
+## Contact info
+
+Сообщайте мне, если вы хотите обсудить любые проблемы, вопросы или комментарии к этому документу.
+
+Моя контактная информация доступна здесь: [GitHub page](https://github.com/donnemartin).
+
+
+
+## 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/
\ No newline at end of file