Fix typos

.github/workflows/l10n-sync-ru.yml

@@ -14,7 +14,7 @@ jobs:
     - uses: actions/checkout@v2
 
     - name: Download mdlm
-      run: curl -o- https://raw.githubusercontent.com/markdown-localization/mdlm-sh/v0.0.18/install.sh | bash      
+      run: curl -o- https://raw.githubusercontent.com/markdown-localization/mdlm-sh/v0.0.20/install.sh | bash      
       
     - name: Sync status - ru
       run: |

README-ru.md

@@ -19,6 +19,7 @@ l10n:p -->
 
 <!-- l10n:ignore start -->
 [![l10n-sync-ru](https://github.com/voitau/system-design-primer/workflows/l10n-sync-ru/badge.svg)](https://github.com/voitau/system-design-primer/actions?query=workflow:l10n-sync-ru)
+<!-- maintained with https://github.com/markdown-localization/mdlm-sh -->
 <!-- l10n:ignore end -->
 
 <p align="center">
@@ -34,11 +35,11 @@ l10n:p -->
 > Prep for the system design interview.
 l10n:p -->
 
-## Мотивация
+## Для чего это нужно
 
-> Узнайте, как проектировать крупномасштабные системы.
+> Чтобы узнать, как проектировать крупномасштабные системы.
 >
-> Подготовьтесь к собеседованию по проектированию системы.
+> Чтобы подготовиться к собеседованию по проектированию систем.
 
 <!-- l10n:p
 ### Learn how to design large-scale systems
@@ -52,9 +53,9 @@ l10n:p -->
 
 ### Научитесь проектировать крупномасштабные системы
 
-Умение проектировать масштабируемые системы поможет вам стать лучшим инженером.
+Умение проектировать масштабируемые системы поможет улучшить ваши инженерные навыки.
 
-Проектирование систем - это широкая тема. В сети есть **огромное количество ресурсов** по принципам проектирования систем.
+Проектирование систем - это обширная тема. В сети есть **огромное количество ресурсов** по принципам проектирования систем.
 
 Этот репозиторий представляет собой **организованную коллекцию** ресурсов, которые помогут вам научиться создавать системы на большом масштабе.
 
@@ -90,7 +91,7 @@ l10n:p -->
 
 ### Подготовка к собеседованию по проектированию систем
 
-В дополнение к интервью по написанию кода, проектирование систем является **обязательным компонентом процесса технического интервью** во многих технологических компаниях.
+Наряду с интервью по написанию кода, проектирование систем является **обязательным компонентом процесса технического интервью** во многих технологических компаниях.
 
 **Практикуйте общие вопросы по проектированию систем** и **сравнивайте** свои результаты с **примерами решений**: обсуждения, код и диаграммы.
 
@@ -124,7 +125,7 @@ l10n:p -->
 <p align="center">
   <img src="images/zdCAkB3.png">
   <br/>
-</p>motivation
+</p>
 
 Предоставленные [карточки Anki](https://apps.ankiweb.net/) могут быть использованы для повторения и запоминания ключевых концепций проектирования систем.
 
@@ -132,8 +133,6 @@ l10n:p -->
 * [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)
 
-Отлично подходят для использования на ходу.
-
 <!-- l10n:p
 ### Coding Resource: Interactive Coding Challenges
 
@@ -158,7 +157,7 @@ l10n:p -->
   <br/>
 </p>
 
-Посмотрите другой репозиторий [**Interactive Coding Challenges**](https://github.com/donnemartin/interactive-coding-challenges), который тоже содержит колоду карт Anki:
+Посмотрите другой репозиторий [**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)
 
@@ -190,7 +189,7 @@ l10n:p -->
 * Добавление новых разделов
 * [Перевод](https://github.com/donnemartin/system-design-primer/issues/28)
 
-Контент, который нуждается в некоторой полировке, помещается в раздел [В разработке](#в-разработке).
+Контент, который нуждается в некоторой доработке, помещается в раздел [В разработке](#в-разработке).
 
 Ознакомьтесь с [Принципами содействия](CONTRIBUTING.md).
 
@@ -386,7 +385,7 @@ l10n:p -->
 - [Безопасность](#безопасность)
 - [Приложение](#приложение)
   - [Таблица степеней двойки](#таблица-степеней-двойки)
-  - [Время выполнения, которое должен знать каждый программист](#время-выполнения-которое-должен-знать-каждый-программист)
+  - [Время выполнения задач, которые должен знать каждый программист](#время-выполнения-задач-которые-должен-знать-каждый-программист)
     - [Визуализация выполнения](#визуализация-выполнения)
   - [Дополнительные вопросы на интервью по проектированию систем](#дополнительные-вопросы-на-интервью-по-проектированию-систем)
   - [Архитектуры действующих систем](#архитектуры-действующих-систем)
@@ -448,13 +447,13 @@ l10n:p -->
 То, что вас будут спрашивать на интервью, зависит от:
 
 * Вашего опыта - сколько времени и чем вы занимались
-* Должности, на которую вы собеседуетесь
+* Должности, на которую вы проходите собеседование
-* Компания, в которую вы собеседуетесь
+* Компании, в которую вы проходите собеседование
-* Удача
+* Как повезёт
 
 Ожидается, что более опытные кандидаты в общем случае знают больше о проектировании систем, а архитекторы и руководители команд знают больше, чем индивидуальные разработчики. Топовые IT компании скорее всего будут проводить один или более этапов собеседования по проектированию систем.
 
-Начинайте широко, и углубляйтесь в некоторые области. Это поможет узнать больше о различных темах по проектированию систем. Корректируйте ваш план в зависимости от того, сколько у вас есть времени, какой у вас опыт, на какую должность вы собеседуетесь и в какие компании.
+Начинайте широко, и углубляйтесь в некоторые области. Это поможет узнать больше о различных темах по проектированию систем. Корректируйте ваш план в зависимости от того, сколько у вас есть времени, какой у вас опыт, на какую должность вы проходите собеседование и в какие компании.
 
 * **Короткий срок** - настраивайтесь на **широту** покрытия тем. Тренируйтесь отвечать на **некоторые** вопросы.
 * **Средний срок** - настраивайтесь на **широту** и **немного глубины** покрытия тем. Тренируйтесь отвечать на **многие** вопросы.
@@ -463,8 +462,8 @@ l10n:p -->
 | | Малый срок | Средний срок | Длительный срок |
 |---|---|---|---|
 | Смотрите [Содержание](#содержание), чтобы получить общее понимание, как работают системы | :+1: | :+1: | :+1: |
-| Почитайте несколько статей из блогов компаний, в который вы собеседуетесь - [Блоги инженерных компаний](#блоги-инженерных-компаний)  | :+1: | :+1: | :+1: |
+| Почитайте несколько статей из блогов компаний, в которые вы проходите собеседование - [Блоги инженерных компаний](#блоги-инженерных-компаний)  | :+1: | :+1: | :+1: |
-| Посмотрите несколько [Архитектур действующих систем](#архитектуры-действующих-систем) | :+1: | :+1: | :+1: |
+| Изучите несколько [Архитектур действующих систем](#архитектуры-действующих-систем) | :+1: | :+1: | :+1: |
 | [Как отвечать на вопросы на интервью по проектированию систем](#как-отвечать-на-вопросы-на-интервью-по-проектированию-систем) | :+1: | :+1: | :+1: |
 | [Вопросы на интервью по проектированию систем с решениями](#вопросы-на-интервью-по-проектированию-систем-с-решениями) | Немного | Много | Большинство |
 | [Вопросы на интервью по объектно-ориентированному программированию с решениями](#вопросы-на-интервью-по-объектно-ориентированному-программированию-с-решениями) | Немного | Много | Большинство |
@@ -504,7 +503,7 @@ l10n:p -->
 
 ### Шаг 1: определите сценарии использования, ограничения и допущения
 
-Соберите требование и оцените рамки задачи. Задавайте вопросы, чтобы уточнить варианты использования и ограничения. Обсудите допущения.
+Соберите требования и оцените рамки задачи. Задавайте вопросы, чтобы уточнить варианты использования и ограничения. Обсудите допущения.
 
 * Кто будет использовать решение?
 * Как его будут использовать?
@@ -513,7 +512,7 @@ l10n:p -->
 * Что система получает на вход, и что должно быть на выходе?
 * Какое количество данных система должна обрабатывать?
 * Сколько ожидается запросов в секунду?
-* Какое соотношение количества операций на чтение и запись?
+* Какое соотношение количества операций чтения и записи?
 
 <!-- l10n:p
 ### Step 2: Create a high level design
@@ -548,7 +547,7 @@ l10n:p -->
 
 ### Шаг 3: Спроектируйте основные компоненты
 
-Детализируйте каждый компонент. Например, если вас попросили разработать [design a url shortening service](solutions/system_design/pastebin/README.md), обсудите следующие моменты:
+Детализируйте каждый компонент. Например, если вас попросили разработать [сервис сокращения URL](solutions/system_design/pastebin/README.md), обсудите следующие моменты:
 
 * Генерация и хранения хэша оригинального URL
     * [MD5](solutions/system_design/pastebin/README.md) и [Base62](solutions/system_design/pastebin/README.md)
@@ -599,7 +598,7 @@ l10n:p -->
 
 * [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)
 * [Таблица степеней двойки](#таблица-степеней-двойки)
-* [Время выполнения, которое должен знать каждый программист](#время-выполнения-которое-должен-знать-каждый-программист)
+* [Время выполнения задач, которые должен знать каждый программист](#время-выполнения-задач-которые-должен-знать-каждый-программист)
 
 <!-- l10n:p
 ### Source(s) and further reading
@@ -645,7 +644,7 @@ l10n:p -->
 
 > Распространенные задачи с обсуждением, кодом и диаграммами.
 >
-> Решение находятся в директории `solutions/`.
+> Решение находятся в папке `solutions/`.
 
 | Задача на проектирование | |
 |---|---|
@@ -796,7 +795,7 @@ l10n:p -->
 
 > Распространенные задачи с обсуждением, кодом и диаграммами.
 >
-> Решение находятся в директории `solutions/`.
+> Решение находятся в папке `solutions/`.
 
 >**Внимание, этот раздел находится в стадии разработки**
 
@@ -805,7 +804,7 @@ l10n:p -->
 | Хэш таблица | [Решение](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/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)  |
 | Циклический массив | [Добавить](#содействуйте)  |
@@ -889,7 +888,7 @@ l10n:p -->
 
 ### Следующие шаги
 
-Далее, изучим компромиссы в общем виде:
+Далее, рассмотрим компромиссы в общем виде:
 
 * **Производительность** и **масштабирование**
 * **Задержка** и **пропускная способность**
@@ -897,7 +896,7 @@ l10n:p -->
 
 Помните, что **везде необходимы компромиссы**.
 
-Далее, изучем более детально DNS, CDN, балансировщики нагрузки и другие темы.
+Далее, рассмотрим более детально DNS, CDN, балансировщики нагрузки и другие темы.
 
 <!-- l10n:p
 ## Performance vs scalability
@@ -945,7 +944,7 @@ l10n:p -->
 
 **Задержка** - это время, необходимое для выполнения действия или достижения некоторого результата.
 
-**Пропускная способность** - это количество такие действий или результататов в единицу времени.
+**Пропускная способность** - это количество таких действий или результатов в единицу времени.
 
 Обычно следует стремиться к **максимальной пропускной способности**, при этом сохраняя **задержку приемлемой**.
 
@@ -1049,7 +1048,7 @@ l10n:p -->
 
 ## Шаблоны реализации согласованности
 
-В распределённой системе можете существовать несколько копий одних и тех же данных. Для достижения согласованности данных, получаемых клиентским приложением, существует несколько подходов синхронизации этих копий. Вспомните определение согласованности из [Теоремы CAP](#теорема-cap) - каждая операция чтения возвращает либо самую записанную версию, либо ошибку.
+В распределённой системе может существовать несколько копий одних и тех же данных. Для достижения согласованности данных, получаемых клиентским приложением, существует несколько подходов синхронизации этих копий. Вспомните определение согласованности из [Теоремы CAP](#теорема-cap) - каждая операция чтения возвращает либо самую последнюю записанную версию, либо ошибку.
 
 <!-- l10n:p
 ### Weak consistency
@@ -1061,9 +1060,9 @@ l10n:p -->
 
 ### Слабая согласованность
 
-После операции записи данных, операция чтения может увидеть эти данные, а может и не увидеть. Используется подход, при котором можно сделать как можно лучше, но с учетом данной ситуации.
+После операции записи данных, операция чтения необязательно вернёт эти данные сразу. Реализуется в системах это настолько, насколько представляется возможным.
 
-Этот подход используется в таких системах, как memcached. Слабая согласованность применяется в таких системах как VoIP, видео чаты и игры реального времени на несколько игроков.
+Этот подход используется в таких системах, как memcached. Слабая согласованность применяется в таких системах как VoIP, видео чаты и многопользовательские игры реального времени. Например, если вы на звонке и на несколько секунд пропала связь, после восстановления связи вы не услышите, что говорили, пока связь отсутствовала.
 
 <!-- l10n:p
 ### Eventual consistency
@@ -1089,7 +1088,7 @@ l10n:p -->
 
 ### Сильная согласованность
 
-После операции записи данных, операция чтения увидит эти данны. Данные реплицируются синхронно.
+После операции записи данных, операция чтения увидит эти данные. Данные реплицируются синхронно.
 
 Такой подход используется в файловых системах и реляционных БД. Сильная согласованность хорошо подходит для систем, где требуются транзакции.
 
@@ -1133,7 +1132,7 @@ l10n:p -->
 
 В таком режиме, активный и пассивный сервер, находящийся в режиме ожидания, обмениваются специальными сообщениями - heartbeats. Если такой сообщение не приходит, то пассивный сервер получает IP адрес активного сервера и восстанавливает работу сервера.
 
-Время простоя определяется в каком состоянии находится пассивный сервер:
+Время простоя определяется состоянием, в котором находится пассивный сервер:
 
 * горячее (hot) ожидание - сервер уже работает
 * холодное (cold) ожидание - сервер должен быть запущен.
@@ -1152,9 +1151,9 @@ l10n:p -->
 
 #### Активный-активный
 
-В таком режиме, оба сервера обрабатывают клиентские запросы, распределяют нагрузку между собой.
+В таком режиме оба сервера обрабатывают клиентские запросы, распределяя нагрузку между собой.
 
-Если сервера имеют общий доступ, то публичные IP адреса обоих серверов должны быть зарегистрированы в DNS. Если сервера находятся во внутренней сети, то клиентское приложение знать про оба сервера.
+Если серверы имеют общий доступ, то публичные IP адреса обоих серверов должны быть зарегистрированы в DNS. Если серверы находятся во внутренней сети, то клиентское приложение должно знать про оба сервера.
 
 Режим "активный-активный" также известен как "Master-Master".
 
@@ -1292,6 +1291,7 @@ l10n:p -->
 Доступность (Общая) = 1 - (1 - Доступность (Foo)) * (1 - Доступность (Bar))
 ```
 
+Если `Foo` и `Bar` имеют доступность 99.9%, их общая доступность при параллельной связи будет 99.9999%.
 <!-- l10n:p
 ## Domain name system
 
@@ -1341,8 +1341,8 @@ DNS иерархична и имеет несколько корневых се
 
 Такие сервисы, как [CloudFlare](https://www.cloudflare.com/dns/) и [Route 53](https://aws.amazon.com/ru/route53/) предоставляют полностью управляемые сервис DNS сервисы. Некоторые DNS сервисы могут направлять трафик, используя различные методы:
 
-* взвешенный цикличекий ([Weighted round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)):
+* взвешенный циклический ([Weighted round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)):
-  * предотвращает попадания трафика на сервера, находящиеся на обслуживании
+  * предотвращает попадание трафика на серверы, находящиеся на обслуживании
   * балансирует трафик для кластера, размер которого может меняться
   * может использоваться для A/B тестирования
 * [на основе задержки отклика серверов](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-latency)
@@ -1401,7 +1401,7 @@ l10n:p -->
   <i><a href=https://www.creative-artworks.eu/why-use-a-content-delivery-network-cdn/>Источник: Why use a CDN</a></i>
 </p>
 
-Сеть доставки содержимого (Content Delivery Network, CDN) - это глобальная распределённая сеть прокси-серверов, которые доставляют содержимое с серверов, наиболее близко находящихся к пользователю. Обычно в CDN размещаются статические файлы, такие как HTML/CSS/JS, фотографии и видео. Некоторые сервисы, как, например Amazon CloudFront, поддерживают доставку динамического содержимого. DNS запрос на сайт даст ответ на какой DNS сервер клиент должен делать запрос.
+Сеть доставки содержимого (Content Delivery Network, CDN) - это глобальная распределённая сеть прокси-серверов, которые доставляют содержимое с серверов, наиболее близко находящихся к пользователю. Обычно в CDN размещаются статические файлы, такие как HTML/CSS/JS, фотографии и видео. Некоторые сервисы, как, например Amazon CloudFront, поддерживают доставку динамического содержимого. DNS запрос на сайт даст ответ на какой CDN сервер клиент должен делать запрос.
 
 Раздача содержимого из CDN может значительно улучшить производительность по двум причинам:
 
@@ -1420,6 +1420,7 @@ l10n:p -->
 
 Содержимое Push CDN обновляется тогда, когда оно обновляется на сервере. Разработчик сайта загружает содержимое на CDN и обновляет соответствующие URL адреса, чтобы они указывали на CDN. Далее, можно сконфигурировать время жизни содержимого в CDN и когда оно должно быть обновлено. Загружается только новое или обновленное содержимое, минимизируя трафик и увеличивая объем хранящихся данных в CDN.
 
+С таким типом CDN хорошо работают сайты с небольшим трафиком, либо сайты с содержимым, которое редко обновляется. Содержимое размещается в CDN один раз, вместо того, чтобы регулярно обновляться.
 <!-- l10n:p
 ### Pull CDNs
 
@@ -1448,7 +1449,7 @@ l10n:p -->
 
 ### Недостатки CDN
 
-* Стоимость CDN может быть высока и зависит от объема трафика, но стоит иметь в виду и дополнительные расходы, которые будут если CDN не использовать.
+* Стоимость CDN может быть высока и зависит от объема трафика, но стоит иметь в виду и дополнительные расходы, которые будут, если CDN не использовать.
 * Содержимое в CDN может оказаться устаревшим, если оно будет обновлено до того, как истечет время жизни (TTL).
 * Исходные URL ссылки должны быть изменены и указывать на CDN.
 
@@ -1542,7 +1543,7 @@ l10n:p -->
 
 ### Layer 4 балансировка
 
-Для распределения запросов балансировщики 4го уровня используют [Транспортный уровень](#взаимодействие) модели OSI. Обычно, используются IP адрес и порт источника и получателя из заголовков пакетов, но не из их содержимого. Балансировщики этого уровня перенаправляют сетевые пакеты с серверов, используя [Network Address Translation (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/).
+Для распределения запросов балансировщики 4-го уровня используют [Транспортный уровень](#взаимодействие) модели OSI. Обычно, используются IP адрес и порт источника и получателя из заголовков пакетов, но не из их содержимого. Балансировщики этого уровня перенаправляют сетевые пакеты с серверов, используя [Network Address Translation (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/).
 
 <!-- l10n:p
 ### Layer 7 load balancing
@@ -1554,7 +1555,7 @@ l10n:p -->
 
 ### Layer 7 балансировка
 
-Для распределения запросов балансировщики 7го уровня используют [Прикладной уровень](#взаимодействие) модели OSI. Для этого могут быть задействованы заголовок, сообщение и куки. Балансировщики на этом уровне прерывают сетевой трафик, сканируют сообщение, принимают решение, куда отправить запрос и открывают соединение с выбранным сервером. Например, они могут отправить запрос на видео на видео-сервер, а запрос на биллинг - на сервера с усиленной безопасностью.
+Для распределения запросов балансировщики 7го уровня используют [Прикладной уровень](#взаимодействие) модели OSI. Для этого могут быть задействованы заголовок, сообщение и куки. Балансировщики на этом уровне прерывают сетевой трафик, сканируют сообщение, принимают решение, куда отправить запрос и открывают соединение с выбранным сервером. Например, они могут отправить видео запрос на видео-сервер, а биллинг запрос - на серверы с усиленной безопасностью.
 
 Балансировка на 4м уровне быстрее и требует меньше ресурсов, чем на 7м уровне, но имеет меньшую гибкость. Хотя на современном аппаратном обеспечении эта разница может быть незаметна.
 
@@ -1596,7 +1597,7 @@ l10n:p -->
 
 * Балансировщик нагрузки может стать узким местом в производительности системы, если он неправильно настроен или его аппаратное обеспечение слишком слабое.
 * Балансировщик нагрузки позволяет избежать единой точки отказа, но увеличивает совокупную сложность всей системы.
-* Единственный балансировщик становится единой точкой отказа, использование нескольких балансировщиком еще больше усложняет систему.
+* Единственный балансировщик становится единой точкой отказа, использование нескольких балансировщиков еще больше усложняет систему.
 
 <!-- l10n:p
 ### Source(s) and further reading
@@ -1656,13 +1657,13 @@ l10n:p -->
   <br/>
 </p>
 
-Обратный прокси-сервер - это веб-сервер, который централизует внутренние сервисы и предоставляет унифицированный интерфейс для доступа из публичной сети. Клиентские запросы перенаправляются на сервер, который их будет обрабатывать, и затем обратный прокси возвращает ответ клиенту.
+Обратный прокси-сервер - это веб-сервер, который централизует внутренние сервисы и предоставляет для них унифицированный интерфейс для доступа из публичной сети. Клиентские запросы перенаправляются на сервер, который их будет обрабатывать, и затем обратный прокси возвращает ответ клиенту.
 
 Дополнительные преимущества:
 
 * **повышенная безопасность** - скрывает информацию о бэкенд-серверах, блокирует IP адреса, ограничивает допустимое количество соединений на клиента
 * **повышенная масштабируемость и гибкость** - клиентское приложение знает только IP адрес прокси-сервера, таким образом можно менять количество серверов или изменять их конфигурацию
-* **SSL терминация** - расшифровка входящих запросов и шифровка ответов; в таком случае бэкенд-сервера не тратят свои ресурсы на эти потенциально трудоемкие операции
+* **SSL терминация** - расшифровка входящих запросов и шифровка ответов; в таком случае бэкенд-серверы не тратят свои ресурсы на эти потенциально трудоемкие операции
   * нет необходимости устанавливать [X.509 сертификаты](https://ru.wikipedia.org/wiki/X.509)
 * **Сжатие** - сжатие ответов сервера клиенту
 * **Кэширование** - возвращает ответы для закэшированных запросов
@@ -1684,7 +1685,7 @@ l10n:p -->
 
 * Использование балансировщика нагрузки полезно при наличии нескольких серверов. Часто балансировщики направляют трафик на сервера, выполняющие одинаковую функцию.
 * Обратный прокси-сервер может быть полезен даже при использовании одного веб-сервера или сервера приложений, предоставляет преимущества, описанные в предыдущей секции
-* Такие решения, как NGINX и HAProxy могут поддерживать как реверс-прокси 7го уровня, так и балансировку нагрузки
+* Такие решения, как NGINX и HAProxy могут поддерживать как обратный прокси-сервер 7го уровня, так и балансировку нагрузки
 
 <!-- l10n:p
 ### Disadvantage(s): reverse proxy
@@ -1736,7 +1737,7 @@ l10n:p -->
   <i><a href=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Source: Intro to architecting systems for scale</a></i>
 </p>
 
-Разделение веб-уровня и уровня приложения (так же известного как уровень платформы) позволяет масштабировать и настраивать оба уровня независимо. Для добавления нового API может понадобиться добавление нового сервера на уровне приложение, но необязательно на веб-уровне. **Принцип единой ответственности** подразумевает создание небольших и автономных сервисов, который работают вместе. Небольшие команды с небольшими сервисами могут быстрее расти.
+Разделение веб-уровня и уровня приложения (так же известного как уровень платформы) позволяет масштабировать и настраивать оба уровня независимо. Для добавления нового API может понадобиться добавление нового сервера на уровне приложения, но необязательно на веб-уровне. **Принцип единственной ответственности** подразумевает создание небольших и автономных сервисов, который работают вместе. Небольшие команды с небольшими сервисами могут быстрее расти.
 
 Worker-сервера на уровне приложений позволяют поддерживать [Асинхронность](#асинхронность).
 
@@ -1752,7 +1753,7 @@ l10n:p -->
 
 [Микросервисная архитектура](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0) может быть описана как набор независимо развёртываемых, небольших, модульных сервисов. Каждый сервис работает как независимый процесс и взаимодействует на основе предустановленного легковесного протокола для обслуживания бизнес задачи. <sup><a href=https://smartbear.com/learn/api-design/what-are-microservices>1</a></sup>
 
-Микросервисы Pinterest могут включать: профиль пользователя, подписчик, лента, поиск, загрузка фото и т.д.
+Примеры микросервисов в Pinterest: профиль пользователя, подписчик, лента, поиск, загрузка фото и т.д.
 
 <!-- l10n:p
 ### Service Discovery
@@ -1762,7 +1763,7 @@ l10n:p -->
 
 ### Обнаружение сервисов (Service Discovery)
 
-Ведя учет зарегистрированных имен, адресов и портов, такие системы как [Consul](https://www.consul.io/docs/index.html), [Etcd](https://coreos.com/etcd/docs/latest), и [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) помогают сервисам находит друг друга. Проверки состояния [Health checks](https://www.consul.io/intro/getting-started/checks.html) позволяют убедиться в работоспособности сервера с помощью [HTTP](#http-hypertext-transfer-protocol) запросы. Consul и Etcd имеют [Хранилище типа ключ-значение](#хранилище-типа-ключ-значение), которое может быть полезно для хранения конфигурации и других общих данных.
+Ведя учет зарегистрированных имен, адресов и портов, такие системы как [Consul](https://www.consul.io/docs/index.html), [Etcd](https://coreos.com/etcd/docs/latest), и [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) помогают сервисам находить друг друга. Проверки состояния [Health checks](https://www.consul.io/intro/getting-started/checks.html) позволяют убедиться в работоспособности сервера с помощью [HTTP](#http-hypertext-transfer-protocol) запроса. Consul и Etcd имеют [Хранилище типа ключ-значение](#хранилище-типа-ключ-значение), которое может быть полезно для хранения конфигурации и других общих данных.
 
 <!-- l10n:p
 ### Disadvantage(s): application layer
@@ -1835,7 +1836,7 @@ l10n:p -->
 
 * **Атомарность (Atomicity)** - каждая транзакция выполняется либо целиком, либо не выполняется совсем (откатывается)
 * **Согласованность (Consistency)** - любая транзакция переводит базу данных из одного правильного состояния в другое правильное состояние, сохраняя согласованность данных
-* **Изолированность (Isolation)** - параллельное выполнение транзакцией должно иметь такие же результаты, как и их последовательное выполнение
+* **Изолированность (Isolation)** - параллельное выполнение транзакций должно иметь такие же результаты, как и их последовательное выполнение
 * **Стойкость (Durability)** - после завершение транзакции, данные должны остаться сохранёнными
 
 Существует ряд подходов для масштабирования реляционных баз данных:
@@ -1845,7 +1846,7 @@ l10n:p -->
 * федерализация
 * шардирование
 * денормализация
-* SQL тюнинг
+* оптимизация SQL запросов
 
 <!-- l10n:p
 #### Master-slave replication
@@ -1880,7 +1881,7 @@ l10n:p -->
 ##### Недостатки репликации master-slave
 
 * Для переключения ведомого сервера в ведущий необходима дополнительная логика
-* См. [Недостатки репликации](#недостатки-репликации) для пунктом, характерных для подходов "Master-Slave" и "Master-Master".
+* См. [Недостатки репликации](#недостатки-репликации) для особенностей, характерных для подходов "Master-Slave" и "Master-Master".
 
 <!-- l10n:p
 #### Master-master replication
@@ -1896,7 +1897,7 @@ l10n:p -->
 
 #### Репликация Master-Master
 
-Оба ведущих сервера работают на чтение и запись и координирует операции записи между собою. Если один из ведущих серверов перестают работать, система может продолжать работать на чтение и запись.
+Оба ведущих сервера работают на чтение и запись и координирует операции записи между собою. Если один из ведущих серверов перестаёт работать, система может продолжать работать на чтение и запись.
 
 <p align="center">
   <img src="images/krAHLGg.png">
@@ -1917,7 +1918,7 @@ l10n:p -->
 
 * Необходим балансировщик нагрузки или понадобиться изменить логику приложение для определения куда будет идти запись.
 * Большинство систем "Master-Master" либо слабо согласованы (нарушая ACID) либо имеют большую задержку из-за необходимости синхронизации.
-* При возрастании количества серверов на запись (ведущих) возрастает задержка и возникает необходимость разрешения конфликтов.
+* При возрастании количества серверов для записи данных (ведущих) возрастает задержка и возникает необходимость разрешения конфликтов.
 * См. [Недостатки репликации](#недостатки-репликации) для пунктом, характерных для подходов "Master-Slave" и "Master-Master".
 
 <!-- l10n:p
@@ -1933,7 +1934,7 @@ l10n:p -->
 ##### Недостатки репликации
 
 * Существует риск потери данных, если ведущий сервер перестает работать до того, как новые данные будут реплицированы на другие сервера.
-* Операции записи реплицируются на ведомый сервера. Если совершается много операций на запись, ведомые сервера могут быть перегружены реплицированием этих операций, влияя на производительность операций на чтение.
+* Операции записи реплицируются на ведомый сервера. Если совершается много операций записи, ведомые сервера могут быть перегружены реплицированием этих операций, влияя на производительность операций чтения.
 * С ростом количества ведомых серверов увеличивается объем репликации, что приводит к задержке репликации.
 * На некоторых системах, запись на ведущем сервере может делаться в несколько потоков, выполняемых параллельно. Запись на ведомых серверах происходит последовательно в один поток.
 * Репликация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
@@ -1986,7 +1987,7 @@ l10n:p -->
 
 * Федерализация неэффективна, если схема базы данных требует больших функций или таблиц.
 * Необходимо изменить логику приложения, чтобы определить, с какими базами данных работать.
-* Операция соединения данных (JOIN) становится сложнее [server link](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers).
+* Операция соединения данных (JOIN) становится сложнее с [server link](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers).
 * Федерализация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
 
 <!-- l10n:p
@@ -2023,9 +2024,9 @@ l10n:p -->
   <i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Источник: Scalability, availability, stability, patterns</a></i>
 </p>
 
-Шардирование распределяет данные между разными базами данных так, что каждая база данных управляет только частью данных. Например, с увеличением количества пользователей в базу данных пользователей добавляются новые сервера (шарды).
+Шардирование распределяет данные между разными базами данных так, что каждая база данных управляет только частью данных. Например, с увеличением количества пользователей в базу данных пользователей добавляются новые серверы (шарды).
 
-Аналогично [Федерализации](#федерализация), шардирование уменьшает количество операций записи и чтения на каждый сервер, уменьшая репликацию и улучшая кэширование. Размер индексов также уменьшается, что приводит к улучшение производительность и более быстрым запросам. Если один из шардов выходит из строя, другие шарды продолжают работать. Во избежание потери данных можно ввести дополнительную репликацию данных. Так же как и с федерализацией, нету централизованного сервера на запись, что позволяет делать запись параллельно, увеличивая пропускную способность.
+Аналогично [Федерализации](#федерализация), шардирование уменьшает количество операций записи и чтения на каждый сервер, уменьшая репликацию и улучшая кэширование. Размер индексов также уменьшается, что приводит к улучшению производительности и более быстрым запросам. Если один из шардов выходит из строя, другие шарды продолжают работать. Во избежание потери данных можно ввести дополнительную репликацию данных. Так же как и с федерализацией, нету централизованного сервера на запись, что позволяет делать запись параллельно, увеличивая пропускную способность.
 
 Распространённый подход шардирования таблицы пользователей основан на разделении по имени или местоположению.
 
@@ -2073,11 +2074,11 @@ l10n:p -->
 
 #### Денормализация
 
-Денормализация - это попытка улучшить скорость чтения за счет производительности записи. Избыточные копии данных записываются в несколько таблиц для избежания сложных операций соединения данных. Некоторый СУБД, например [PostgreSQL](https://ru.wikipedia.org/wiki/PostgreSQL) и Oracle поддерживают [материализованное представление](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5), которые выполнюят задачу хранения избыточных данных и поддержку их согласованности.
+Денормализация - это попытка улучшить скорость чтения за счет производительности записи. Избыточные копии данных записываются в несколько таблиц для избежания сложных операций соединения данных. Некоторый СУБД, например [PostgreSQL](https://ru.wikipedia.org/wiki/PostgreSQL) и Oracle поддерживают [материализованное представление](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5), которое выполняют задачу хранения избыточных данных и поддержку их согласованности.
 
 При использовании [Федерализации](#федерализация) и [Шардирования](#шардирование), данные становятся распределенными. В результате выполнение операций соединения данных, которые могут находится в разных дата-центрах, усложняется. Денормализация может позволить избавиться от необходимости в сложных JOIN запросах.
 
-В большинстве систем, количество операций на чтение значительно больше операций на запись (100:1, или даже 1000:1). Операция на чтение в результате сложного соединения данных может быть очень ресурсоемкой и требовать значительного времени, потраченного на операции c жестким диском.
+В большинстве систем, количество операций чтения значительно больше операций записи (100:1, или даже 1000:1). Операция чтения в результате сложного соединения данных может быть очень ресурсоемкой и требовать значительного времени, потраченного на операции c жестким диском.
 
 <!-- l10n:p
 ##### Disadvantage(s): denormalization
@@ -2116,9 +2117,9 @@ It's important to **benchmark** and **profile** to simulate and uncover bottlene
 Benchmarking and profiling might point you to the following optimizations.
 l10n:p -->
 
-#### SQL тюнинг
+#### Оптимизация SQL запросов
 
-SQL тюнинг - это обширная тема, описанная во многих [книгах](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning)).
+Оптимизация SQL запросов - это обширная тема, описанная во многих [книгах](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning).
 
 Очень важно проводить **бенчмарки** и **профилирование** для имитации и обнаружения узких мест.
 
@@ -2149,7 +2150,7 @@ l10n:p -->
 * Используйте `TEXT` для больших фрагментов текста (например, блог-посты). `TEXT` позволяет делать булевый поиск. Использование поля типа `TEXT` приводит к хранению указателя на диске, которые используется для поиска этого блока.
 * Используйте `INT` для больших чисел до 2^32.
 * Используйте `DECIMAL` для денежных единиц для избежания ошибок, связанных с представлением в формате с плавающей точкой.
-* Избегайте хранения больших `BLOBS`, вместо этого хранение указателя на место хранения объекта.
+* Избегайте хранения больших `BLOBS`, вместо храните указатель на объект.
 * Установите ограничения `NOT NULL`, где возможно, для улучшения производительности ([improve search performance](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)).
 
 
@@ -2167,9 +2168,9 @@ l10n:p -->
 
 * Запрос столбцов (включая операторы `SELECT`, `GROUP BY`, `ORDER BY`, `JOIN`) может быть быстрее с индексами.
 * Индексы обычно представляют собой самобалансирующиеся [B-деревья](https://ru.wikipedia.org/wiki/B-%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%BE), которые хранят данные отсортированными, позволяют поиск, последовательный доступ, вставку и удаление с логарифмической сложностью.
-* Создание индексы может потребовать хранения данных в памяти, требуя больше места.
+* Добавление индекса может потребовать хранения данных в памяти, требуя больше места.
 * Операции записи могут быть медленнее, так как индекс тоже необходимо обновлять.
-* При загрузке большого объема данных отключение индексов может помочь для ускорения этой операции; индексы в таком случае обновляются после загрузки данных.
+* При загрузке большого объема данных отключение индексов может помочь для ускорения этой операции. индексы в таком случае обновляются после загрузки данных.
 
 <!-- l10n:p
 ##### Avoid expensive joins
@@ -2179,7 +2180,7 @@ l10n:p -->
 
 ##### Избегайте больших объединений
 
-* [Денормализаруйте](#денормализация), если необходимо повысить производительность.
+* [Денормализируйте](#денормализация), если необходимо повысить производительность.
 
 <!-- l10n:p
 ##### Partition tables
@@ -2233,12 +2234,12 @@ l10n:p -->
 
 ### NoSQL
 
-NoSQL - это набор данных, представленных в виде **базы ключ-значение**, **документориентированной базы данных**, **колоночной базы данных** или **графовой база данных**. Данные денормализованы и операции соединения данных обычно происходят на уровне кода. Большинство NoSQL хранилищ не поддерживают ACID свойств транзакий и характеризуются [согласованностью в конечном счете](https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_%D0%BA%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D0%BE%D0%BC_%D1%81%D1%87%D1%91%D1%82%D0%B5).
+NoSQL - это набор данных, представленных в виде **базы ключ-значение**, **документориентированной базы данных**, **колоночной базы данных** или **графовой база данных**. Данные денормализованы и операции соединения данных обычно происходят на уровне кода. Большинство NoSQL хранилищ не поддерживают ACID свойства транзакций и характеризуются [согласованностью в конечном счете](https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_%D0%BA%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D0%BE%D0%BC_%D1%81%D1%87%D1%91%D1%82%D0%B5).
 
-Для описания свойств NoSQL баз данных используют **BASE** свойства. Согласно [Теорема CAP](#теорема-cap), BASE придерживается доступности данных, а не их согласованности.
+Для описания свойств NoSQL баз данных используют **BASE** свойства. Согласно [Теореме CAP](#теорема-cap), BASE придерживается доступности данных, а не их согласованности.
 
 * **В целом доступные** - система гарантирует доступность.
-* **Неокончательное (soft) удаление** - состояние ситемы может со временем измениться, даже без дополнительный операций.
+* **Неокончательное (soft) удаление** - состояние ситемы может со временем измениться, даже без дополнительных операций.
 * **Согласованность в конечном счете (eventual consistency)** - данные в системе станут согласованными в течение некоторого времени, если в течение этого времени не будут приходить новые данные.
 
 Вместе с выбором между [SQL или NoSQL](#sql-или-nosql), надо сделать выбор типа NoSQL базы данных, которая подходит для вашего сценария использования. В следующей секции представлены **базы ключ-значение**, **документориентированные базы данных**, **колоночные базы данных** или **графовые база данных**.
@@ -2401,7 +2402,7 @@ l10n:p -->
 
 В графовой базе данных, каждый узел это запись, а ребра это связь между двумя узлами. Графовые базы данных оптимизированы для представление сложных связей с множеством внешних ключей или связей многих ко многим.
 
-Графовые базы данных имеют высокую производительность для моделей данных со сложными связями, как в социальных сетях. Они относительно новые и не пока не используются широко. Может быть сложно найти средства и ресурсы для их разработки. Получить доступ ко многим графам можно только с помощью [REST API](#rest-representational-state-transfer).
+Графовые базы данных имеют высокую производительность для моделей данных со сложными связями, как в социальных сетях. Они относительно новые и пока не используются широко. Может быть сложно найти средства и ресурсы для их разработки. Получить доступ ко многим графам можно только с помощью [REST API](#rest-representational-state-transfer).
 <!-- l10n:p
 ##### Source(s) and further reading: graph
 
@@ -2504,7 +2505,7 @@ l10n:p -->
 
 Примеры данных, хорошо подходящих для NoSQL:
 
-* Скоростное сохранение clickstream данных и данных журналирования (logs)
+* Быстрое сохранение данных потоков кликов (clickstream) и данных журналирования (logs)
 * Список лидеров или общий счет
 * Временные данные, например, корзина
 * Таблицы с частым доступом (горячие таблицы)
@@ -2544,7 +2545,7 @@ l10n:p -->
   <i><a href=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Источник: Scalable system design patterns</a></i>
 </p>
 
-Кэширование улучшает время загрузки страницы и может уменьшить нагрузку на сервера и базы данных. При таком подходе, диспетчер вначале проверяет, делался ли запрос ране, чтобы найти ответ, который уже на него возвращался, сократив при этом время выполнения текущего запроса.
+Кэширование улучшает время загрузки страницы и может уменьшить нагрузку на серверы и базы данных. При таком подходе, диспетчер вначале проверяет, делался ли запрос ранее, чтобы найти ответ, который уже на него возвращался, сократив при этом время выполнения текущего запроса.
 
 Базы данных работают оптимальным образом при равномерном распределении операций чтения и записи между их партициями (partitions). Популярные элементы могут нарушить равномерность распределения, создавая узкие места. Добавление системы кэширование перед базой данных может позволить сгладить неравномерность поступающего трафика.
 
@@ -2576,7 +2577,7 @@ l10n:p -->
 
 ### Кэширование на веб-сервере
 
-[Обратные прокси-сервера](#обратный-прокси-сервер-reverse-proxy) и системы такие системы кэширование как [Varnish](https://www.varnish-cache.org/) могут выдавать как статический, так и динамический контент. Веб-сервера тоже могут кэшировать запросы, возвращая ответы не обращаюсь к серверам приложений.
+[Обратные прокси-сервера](#обратный-прокси-сервер-reverse-proxy) и такие системы кэширования как [Varnish](https://www.varnish-cache.org/) могут выдавать как статический, так и динамический контент. Веб-серверы тоже могут кэшировать запросы, возвращая ответы не обращаюсь к серверам приложений.
 
 <!-- l10n:p
 ### Database caching
@@ -2586,7 +2587,7 @@ l10n:p -->
 
 ### Кэширование в Базах данных
 
-База данных обычно включает какое-то кэширование в конфигурации по умолчанию, которое оптимизировано для стандартных сценариев использования. Настройка этих параметров для конкретных шаблонов использования данных может еще больше увеличить её производительность.
+Базы данных в конфигурации по умолчанию обычно уже включают кэширование, которое оптимизировано для стандартных сценариев использования. Настройка этих параметров для конкретных сценариев использования данных может еще больше улучшить её производительность.
 
 <!-- l10n:p
 ### Application caching
@@ -2610,7 +2611,7 @@ l10n:p -->
 
 ### Кэширование в приложениях
 
-Системы кэширования в памяти (например, Memcached и Redis) являются хранилищами типа "ключ-значение", которые находятся между вашим приложением и хранилищем данных. Они обычно быстрее, так как данных хранятся в оперативной памяти, а не на жестком диске, как это обычно бывает в случае с базами данных. Количество оперативной памяти имеет больше ограничений, чем жесткий диск, поэтому [алгоритмы очистки кэша](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F), как например [вытеснение давно неиспользуемых (Least recently used, LRU)](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F#Least_recently_used_(%D0%92%D1%8B%D1%82%D0%B5%D1%81%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%B0%D0%B2%D0%BD%D0%BE_%D0%BD%D0%B5%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D0%BC%D1%8B%D1%85)) помогают удалять из кэша "холодные" записи и оставлять в памяти "горячие".
+Системы кэширования в памяти (например, Memcached и Redis) являются хранилищами типа "ключ-значение", которые находятся между вашим приложением и хранилищем данных. Они обычно быстрее, так как данныe хранятся в оперативной памяти, а не на жестком диске, как это обычно бывает в случае с базами данных. Количество оперативной памяти имеет больше ограничений, чем жесткий диск, поэтому [алгоритмы очистки кэша](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F), как например [вытеснение давно неиспользуемых (Least recently used, LRU)](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D1%8B_%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F#Least_recently_used_(%D0%92%D1%8B%D1%82%D0%B5%D1%81%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%B0%D0%B2%D0%BD%D0%BE_%D0%BD%D0%B5%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D0%BC%D1%8B%D1%85)) помогают удалять из кэша "холодные" записи и оставлять в памяти "горячие".
 
 Redis включает дополнительную функциональность:
 
@@ -2637,10 +2638,10 @@ l10n:p -->
 
 ### Кэширование на уровне запросов в базу данных
 
-При таком подходе результат сохраняется с ключом, которым является вычисленное хэш-значение для запросы в базу данных. Такой подход имеет ряд недостатков:
+При таком подходе результат сохраняется с ключом, которым является вычисленное хэш-значение для запроса в базу данных. Такой подход имеет ряд недостатков:
 
 * Тяжело удалить закэшированный результат сложных запросов
-* Если меняется значение одной ячейки данных, необходимо удалить все запросы, который могут содержать эти данные
+* Если меняется значение одной ячейки данных, необходимо удалить все запросы, которые могут содержать эти данные
 
 <!-- l10n:p
 ### Caching at the object level
@@ -2663,7 +2664,7 @@ l10n:p -->
 При таком подходе данные рассматриваются как объекты, аналогично объектам в коде приложения. Приложение собирает данные из базы в объект класса или структуру(ы) данных:
 
 * Объект удаляется из кэша, если структура данных, которую он представляет, изменилась
-* Возможна асинхронная обработка: новые объекты могуть собираться из текущий версий закэшированных объектов
+* Возможна асинхронная обработка: новые объекты могуть собираться из текущий версии закэшированных объектов
 
 Что можно кэшировать как объекты:
 
@@ -2742,7 +2743,7 @@ def get_user(self, user_id):
 
 Обычно так используется [Memcached](https://memcached.org/).
 
-Последующие запросы на чтение данных, находящиейся в кэши, выполняются быстро. Также такой подход известен как ленивая загрузка. Только запрашиваемые данные попадают в систему кэширование, и не происходит его заполнения данными, которые не запрашиваются.
+Последующие запросы на чтение данных, находящихся в кэше, выполняются быстро. Такой подход также известен как ленивая загрузка. Только запрашиваемые данные попадают в систему кэширование, и не происходит её заполнения данными, которые не запрашиваются.
 
 <!-- l10n:p
 ##### Disadvantage(s): cache-aside
@@ -2798,7 +2799,7 @@ l10n:p -->
   <i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Источник: Scalability, availability, stability, patterns</a></i>
 </p>
 
-Приложение использует систему кэширования, как основной источник данных, считывая и записывая данные в него. Система кэширования в свою очередь записывает и считывает данных из БД:
+Приложение использует систему кэширования, как основной источник данных, считывая и записывая данные в него. Система кэширования в свою очередь записывает и считывает данные из БД:
 
 * Приложение добавляет и обновляет элемент в системе кэширования
 * Система кэширования синхронно записывает данные в БД
@@ -2829,7 +2830,7 @@ l10n:p -->
 
 ##### Недостатки кэширование Write through
 
-* Когда добавляется новый сервер из-за отказа другого, либо масштабирование, его кэш не содержит никаких элементов, пока данные не обновятся в БД. Использование "отдельного" кэша может помочь смягчить последствия этой проблемы
+* Когда добавляется новый сервер из-за отказа другого, либо в результате масштабирования, его кэш не содержит никаких элементов, пока данные не обновятся в БД. Использование "отдельного" кэша может помочь смягчить последствия этой проблемы
 * Большая часть записываемых данных может вообще не использоваться. Использование времени жизни данных (TTL) может смягчить последствия этой проблемы.
 
 <!-- l10n:p
@@ -2896,7 +2897,7 @@ l10n:p -->
 
 При таком подходе можно настроить автоматическое обновление закэшированных данных, к которым недавно обращались, не ожидая истечения их срока действия.
 
-Кэширование методом "предварительного обновление" может уменьшить задержку, по сравнению с кэшем, который делает сквозное чтение, если можно точно определить, какие элементы могут быть запрошены в будущем.
+Кэширование методом "предварительного обновления" может уменьшить задержку, по сравнению с кэшем, который делает сквозное чтение, если можно точно определить, какие элементы могут быть запрошены в будущем.
 
 <!-- l10n:p
 ##### Disadvantage(s): refresh-ahead
@@ -3009,7 +3010,7 @@ l10n:p -->
 
 ### Очереди задач
 
-Очереди сообщений принимают задачи и связанные с ними данные, выполняют их, и затем доставляет их результаты. Они могут поддерживать планирование и использоваться для выполнения задач, которые требуют высоких вычислительных мощностей, в фоне.
+Очереди задач принимают задачи и связанные с ними данные, выполняют их, и затем выдают их результаты. Они могут поддерживать планирование и использоваться для выполнения задач, которые требуют высоких вычислительных мощностей, в фоне.
 
 Планирование есть в **[Celery](https://docs.celeryproject.org/en/stable/)**, который в основном поддерживается на Python.
 
@@ -3021,7 +3022,7 @@ l10n:p -->
 
 ### Обратное давление
 
-Если очередь достигает больших размеров, ее размер может стать больше памяти, что приведет к запросу элементов, которых нет в кэши, увеличению количества операций чтения с жесткого диска и ухудшению производительности. [Обратное давление](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) может помочь, ограничивая размер очереди и поддерживая высокую пропускную способность и хорошее время отклика для задач, которые уже находятся в очереди. Как только очередь заполнится, клиентские приложения получают 503 код состояния HTTP ("Сервис недоступен"). Клиенты могут повторить запрос позже, в том числе и с [экспоненциальной выдержкой](https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%B2%D1%8B%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0).
+Если очередь достигает больших размеров, ее размер может стать больше памяти, что приведет к запросу элементов, которых нет в кэше, увеличению количества операций чтения с жесткого диска и ухудшению производительности. [Обратное давление](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) может помочь, ограничивая размер очереди и поддерживая высокую пропускную способность и хорошее время отклика для задач, которые уже находятся в очереди. Как только очередь заполнится, клиентские приложения получают 503 код состояния HTTP ("Сервис недоступен"). Клиенты могут повторить запрос позже, в том числе и с [экспоненциальной выдержкой](https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%B2%D1%8B%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B0).
 
 <!-- l10n:p
 ### Disadvantage(s): asynchronism
@@ -3031,7 +3032,7 @@ l10n:p -->
 
 ### Недостатки асинхронности
 
-* Для простых вычислений и процессов реального времени лучше подойдут синхронные операции, так как введение очередей добавит задержку и усложняет систему.
+* Для простых вычислений и процессов реального времени лучше подойдут синхронные операции, так как введение очередей может добавить задержку и усложнить систему.
 
 <!-- l10n:p
 ### Source(s) and further reading
@@ -3089,7 +3090,7 @@ l10n:p -->
 
 ### HTTP (Hypertext transfer protocol)
 
-HTTP - это метод для кодировки и передачи данных между клиентом и серверов. Этот протокол основан на модели запрос/ответ: клиенты делают запросы, сервера отвечают на них с соответствующим контентом и информацией о состоянии завершения запроса. HTTP самодостаточен, позволяя запросам и ответам свободно передаваться через множество маршрутизаторов и серверов посредников, которые выполняют балансировку, кэширование, шифрование и сжатие.
+HTTP - это метод для кодировки и передачи данных между клиентом и серверов. Этот протокол основан на модели запрос/ответ: клиенты делают запросы, серверы отвечают на них с соответствующим контентом и информацией о состоянии завершения запроса. HTTP самодостаточен, позволяя запросам и ответам свободно передаваться через множество маршрутизаторов и серверов посредников, которые выполняют балансировку, кэширование, шифрование и сжатие.
 
 Стандартный HTTP запрос состоит из глагола (метода) и ресурса (конечной точки (endpoint)). Ниже приведены распространенные HTTP методы:
 
@@ -3153,7 +3154,7 @@ l10n:p -->
   <i><a href=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Источник: How to make a multiplayer game</a></i>
 </p>
 
-TCP - это протокол с установкой соединения, работающих поверх [межсетевого протокола IP](https://ru.wikipedia.org/wiki/IP). Соединение устанавливается и завершается с помощью [рукопожатия](https://en.wikipedia.org/wiki/Handshaking). Гарантия доставки пакетов в оригинальном порядке и без искажений получателю основана на:
+TCP - это протокол с установкой соединения, работающий поверх [межсетевого протокола IP](https://ru.wikipedia.org/wiki/IP). Соединение устанавливается и завершается с помощью [рукопожатия](https://en.wikipedia.org/wiki/Handshaking). Гарантия доставки пакетов получателю в оригинальном порядке и без искажений основана на:
 
 * номерах последовательности и [полем контрольной суммы](https://ru.wikipedia.org/wiki/Transmission_Control_Protocol#%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%81%D1%83%D0%BC%D0%BC%D0%B0_(Checksum))
 * [подтверждении](https://ru.wikipedia.org/wiki/Transmission_Control_Protocol#%D0%9D%D0%BE%D0%BC%D0%B5%D1%80_%D0%BF%D0%BE%D0%B4%D1%82%D0%B2%D0%B5%D1%80%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F) пакетов и автоматической повторной передаче.
@@ -3162,7 +3163,7 @@ TCP - это протокол с установкой соединения, ра
 
 Для поддержки высокой пропускной способности, веб-сервера могут содержать большое количество открытых TCP соединений, что приводит к использованию большого количества оперативной памяти. Ресурсозатратным можем быть поддержание большого количества открытых соединений между потоками веб-сервера и, например, сервером [Memcached](https://memcached.org/). В этом случае может помочь использование [пула соединений](https://en.wikipedia.org/wiki/Connection_pool) и UPD там, где он может быть применим.
 
-TCP полезен для приложений, которым необходимы высокая надежная, но менее требовательным ко времени, например веб-серверы, базы данных, SMTP, FTP, SSH.
+TCP подходит для приложений, которым необходимы высокая надежная, но менее требовательным ко времени, например веб-серверы, базы данных, SMTP, FTP, SSH.
 
 Используйте TCP (а не UDP) в случаях, когда необходимо:
 
@@ -3212,16 +3213,16 @@ l10n:p -->
 
 #### Источники и дополнительные ссылки по TCP и UDP
 
-UPD не требует соединения. Датаграммы (по аналогии с пакетами данных) гарантированы только на уровне датаграммы. Датаграммы могут быть доставлены в другом порядке (отличном от того, в котором они были отправлены), либо не доставлены совсем. UDP не поддерживает контроля перегрузок. Из-за отсутствия гарантий TCP, обычно UDP является более эффективным.
+UPD не требует соединения. Датаграммы (по аналогии с пакетами данных) гарантированы только на уровне датаграммы. Датаграммы могут быть доставлены в порядке, отличном от того, в котором они были отправлены, либо не доставлены совсем. UDP не поддерживает контроля перегрузок. Из-за отсутствия гарантий TCP, обычно UDP является более эффективным.
 
 UDP поддерживает широковещательную передачу данных, отправляя датаграммы всем устройствам подсети. Это полезно использовать вместе с [DHCP](https://ru.wikipedia.org/wiki/DHCP), так как с клиентом, который еще не получил IP адрес, нельзя установить TCP соединение.
 
-UPD менее надежный, но работает хорошо для приложений реального времени, например, VoIP, видеочатов, потоковой передачи данных и мультиплеерных игр реального времени.
+UDP менее надежный, но работает хорошо для приложений реального времени, например, VoIP, видеочатов, потоковой передачи данных и мультиплеерных игр реального времени.
 
-Используйте UPD (а не TCP) в случаях, когда:
+Используйте UDP (а не TCP) в случаях, когда:
 
 * вам необходима минимальная задержка передачи данных
-* данных, которые пришли поздно, хуже, чем потеря данных
+* данные, которые пришли поздно, хуже, чем потеря данных
 * вы хотите сами реализовать исправление ошибок
 
 <!-- l10n:p
@@ -3276,7 +3277,7 @@ l10n:p -->
   <i><a href=http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview>Источник: Crack the system design interview</a></i>
 </p>
 
-При использовании RPC, клиент вызывает выполнение процедуры в другом адресном пространстве, обычно на удаленном сервере. Эта процедура запрограммирована для использования, как локальный вызова, абстрагируя детали взаимодействия сервера и клиенского приложения. Удаленные вызовы обычно медленнее и менее надежны, чем локальные вызовы. Поэтому полезно различать удаленные вызовы от локальных. Популярными RPC фреймворками являются [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/), и [Avro](https://avro.apache.org/docs/current/).
+При использовании RPC, клиент вызывает выполнение процедуры в другом адресном пространстве, обычно на удаленном сервере. Эта процедура запрограммирована для использования, как локальный вызов, абстрагируя детали взаимодействия сервера и клиентского приложения. Удаленные вызовы обычно медленнее и менее надежны, чем локальные вызовы. Поэтому полезно отличать удаленные вызовы от локальных. Популярными RPC фреймворками являются [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/), и [Avro](https://avro.apache.org/docs/current/).
 
 RPC - это протокол на основе запроса и ответа:
 
@@ -3325,7 +3326,7 @@ l10n:p -->
 * клиентские приложения RPC становятся сильно связанными с сервисной реализацией.
 * необходимо делать новое API для каждой новой операции или сценария использования.
 * отладка (debug) вызов RPC может быть непростой.
-* вы, возможно, не сможете использовать существующие технологии как есть "из коробки". Например, могут понадобиться дополнительные действия для того, чтобы убедиться, что [RPC запросы закэшированы]((http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)) на серверах системах кэширования таких, как [Squid](http://www.squid-cache.org/).
+* вы, возможно, не сможете использовать существующие технологии как есть "из коробки". Например, могут понадобиться дополнительные действия для того, чтобы убедиться, что [RPC запросы закэшированы]((http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)) на серверах систем кэширования таких, как, например, [Squid](http://www.squid-cache.org/).
 
 <!-- l10n:p
 ### Representational state transfer (REST)
@@ -3371,7 +3372,7 @@ PUT /someresources/anId
 {"anotherdata": "another value"}
 ```
 
-REST ориентирован на предоставление данных. Он снижает связанность между клиентом и сервером и часто используется для публичных API. REST использует обобщенный и унифицированный метод предоставления ресурсов через URI, [представление через заголовки](https://github.com/for-GET/know-your-http-well/blob/master/headers.md), и действия с помощью методов, таких как GET, POST, PUT, DELETE и PATCH. Не имея состояния, REST хорошо подходит для горизонтального масштабирования и партицирования.
+REST ориентирован на предоставление данных. Он снижает связность между клиентом и сервером и часто используется для публичных API. REST использует обобщенный и унифицированный метод предоставления ресурсов через URI, [представление через заголовки](https://github.com/for-GET/know-your-http-well/blob/master/headers.md), и действия с помощью методов, таких как GET, POST, PUT, DELETE и PATCH. Не имея состояния, REST хорошо подходит для горизонтального масштабирования и партицирования.
 
 <!-- l10n:p
 #### Disadvantage(s): REST
@@ -3384,10 +3385,10 @@ l10n:p -->
 
 #### Недостатки REST
 
-* Учитывая, что REST ориентирован на предоставление данных, этот подход может не подойти, если ресурсы недостаточно организованы или их можно получить в виде простой иерархии. Например, возвращение всех обновленных за последних час записей, соответствующих определенному набору событий не так просто представить в виде пути. Скорее всего, в таком случае реализация будет включать сочетание пути URI, параметров запросы и, возможно, тело запроса.
+* Учитывая, что REST ориентирован на предоставление данных, этот подход может не подойти, если ресурсы недостаточно организованы или их можно получить в виде простой иерархии. Например, возвращение всех обновленных за последних час записей, соответствующих определенному набору событий не так просто представить в виде пути. Скорее всего, в таком случае реализация будет включать сочетание пути URI, параметры запросов и, возможно, тело запроса.
 * REST обычно полагается на несколько методов (GET, POST, PUT, DELETE и PATCH), что не всегда может подходить для вашего сценария использования. Например, нет определенного метода для представления перемещения документов с истекшим сроком в архивную папку.
 * Получение сложных ресурсов с вложенными иерархиями требует нескольких повторных запросов между клиентов и сервером, например, получение контента записи в блоге и комментариев к этой записи. Для мобильных приложений, которые функционируют в условиях переменного качества сети, эти повторные запросы являются крайне нежелательными.
-* С течением времени, больше полей может добавляться в ответ API, и более старые клиенты будут получать все новые поля, даже те, которые не нужны. В результате, увеличивается размер пересылаемых данных, что приводит к увеличению задержки передачи данных.
+* С течением времени, больше полей может добавляться в ответ API, и более старые клиенты будут получать все новые поля, включая даже те, которые не нужны. В результате, увеличивается размер пересылаемых данных, что приводит к увеличению задержки передачи данных.
 
 <!-- l10n:p
 ### RPC and REST calls comparison
@@ -3493,7 +3494,7 @@ l10n:p -->
 
 ## Приложение
 
-Вас иногда могут попросить сделать оценку по времени "на салфетке". Например, определить, сколько времени понадобится для генерации 100 миниатюр изображений с жесткого диска, или сколько памяти потребует структура данных. **Степеней двойки** и **Время выполнения задач, которые должен знать любой программист** могут в этом помочь.
+Вас иногда могут попросить сделать оценку по времени "на салфетке". Например, определить, сколько времени понадобится для генерации 100 миниатюр изображений с жесткого диска, или сколько памяти потребует структура данных. **Таблица степеней двойки** и **Время выполнения задач, которые должен знать любой программист** могут в этом помочь.
 
 <!-- l10n:p
 ### Powers of two table
@@ -3576,7 +3577,7 @@ Handy metrics based on numbers above:
 * 2,000 round trips per second within a data center
 l10n:p -->
 
-### Время выполнения, которое должен знать каждый программист
+### Время выполнения задач, которые должен знать каждый программист
 
 ```
 Время выполнения
@@ -3619,7 +3620,7 @@ l10n:p -->
 ![](https://camo.githubusercontent.com/77f72259e1eb58596b564d1ad823af1853bc60a3/687474703a2f2f692e696d6775722e636f6d2f6b307431652e706e67)
 l10n:p -->
 
-#### Визуализация выполнения
+#### Визуализация времени выполнения задач
 
 ![](https://camo.githubusercontent.com/77f72259e1eb58596b564d1ad823af1853bc60a3/687474703a2f2f692e696d6775722e636f6d2f6b307431652e706e67)
 
@@ -3759,7 +3760,7 @@ l10n:p -->
 
 * Определите основные принципы, общие технологии и шаблоны, которые встречаются в этих статьях
 * Изучите, какие проблемы решаются каждым компонентом, где это работает, а где нет
-* Обратите внимание секции, описывающие полученный опыт и работу над ошибками
+* Обратите внимание на секции, описывающие полученный опыт и работу над ошибками
 
 | Тип | Система | Ссылки |
 |---|---|---|