diff --git a/docs/cluster.png b/docs/cluster.png
new file mode 100644
index 0000000000000000000000000000000000000000..c0f95527833a48b6d2c11549ede3645ae5d3c120
Binary files /dev/null and b/docs/cluster.png differ
diff --git a/docs/cluster_scheme1.png b/docs/cluster_scheme1.png
deleted file mode 100644
index 663bde14ecbfacaff86087e9975c8a3e12f574a0..0000000000000000000000000000000000000000
Binary files a/docs/cluster_scheme1.png and /dev/null differ
diff --git a/docs/description.md b/docs/description.md
index 5520d30638b495991a53057c6d051cb5ea876d87..19cd30086a04996cdd45b8583f050c97d96d4517 100644
--- a/docs/description.md
+++ b/docs/description.md
@@ -36,12 +36,20 @@ Picodata позволяет развёртывать и управлять кл
 * обеспечение высокой доступности и персистентности данных сразу, без использования дополнительного инструментария.
 
 ## Архитектура
-Архитектура кластера под управлением Picodata предполагает систему гомогенных узлов, входящих в состав кластера. Каждый узел может выполнять различные роли, например роль хранения данных, роль сервера приложения, или служебную роль координатора кластера.
-Все узлы работают с единой схемой данных и кодом приложения. Каждый узел выполняется на одном процессорном ядре (1 ядро - 1 процесс). Если рассматривать кластер именно как хранилище, то в нём все данные распределены между узлами, т.е. реплицированы, что означает, что у каждого узла есть как минимум одна реплика. Такие наборы реплицированных узлов называются *репликасетами*, которые считаются единицами физического масштабирования кластера. Число реплик определяется фактором репликации, заданным для набора в глобальных настройках Picodata. У каждого набора всегда есть основная реплика, или *лидер*. В случае отказа лидера репликасета, лидером автоматически становится одна из оставшихся реплик. Данные автоматически балансируются между репликасетами.
+Архитектура кластера под управлением Picodata предполагает систему узлов, входящих в состав кластера. Каждый узел может выполнять различные роли, например роль хранения данных, роль сервера приложения, или служебную роль координатора кластера.
+Все узлы работают с единой схемой данных и кодом приложения. Каждый процесс базы данных выполняется на одном процессорном ядре и хранит все свои данные в оперативной памяти. 
+Любой отдельный узел является часть набора реплик, который также называют *репликасетом*. Репликасет может состоять из одного узла или нескольких дубликатов одного и того же набора данных. Внутри репликасета всегда есть *лидер* (основной узел) и - если реплик больше 1 - то некоторое число вспомогательных узлов, обеспечивающие отказоустойчивость системы в случае выхода из строя или недоступности лидера. Число реплик определяется *фактором репликации*, заданным для набора в глобальных настройках Picodata.
+
+На рисунке ниже показана схема простого кластера из двух репликасетов, каждый из которых состоит из двух узлов (активного и в ожидании):
+
+![Схема кластера](cluster.png){ align=left }
+
+Репликасеты являются единицами физического масштабирования кластера. Данные балансируются между ними автоматически.
 Внутри каждого репликасета есть *bucket* - виртуализированная единица хранения, обеспечивающая локальность данных (например, хранение нескольких связанных с клиентом записей на одном физическом узле). Таким образом, при горизонтальном масштабировании кластера данные распределяются по устройствам хранения не напрямую, а внутри bucket'ов. Это позволяет увеличить скорость выполнения запросов к БД и одновременно с этим снизить нагрузку на сетевую инфраструктуру кластера.
 
-На схеме ниже показано устройство шардированного кластера, распределенного по трем датацентрам:
-![Image title](cluster_scheme1.png){ align=left }
+На схеме ниже показан пример шардирования элементов кластера путём распределения репликасетов по нескольким серверам:
+
+![Принцип шардирования](sharding.png){ align=left }
 
-Красным показана связь активных узлов (инстансов) посредством встроенной библиотеки шардирования, а серым - связь узлов, находящихся в режиме hot standby, т.е. готовых вступить в работу в случае роста объёмов хранения данных или увеличения вычислительной нагрузки.
-Каждый bucket в любой момент времени может находиться только в одном репликасете. В то же время, в репликасете может быть несколько bucket'ов, или не быть ни одного. Внутри bucket'а данные распределены по двум или более узлам в рамках репликасета.
\ No newline at end of file
+В свою очередь, сервера могут находиться в разных дата-центрах и быть географически распределены. С точки зрения администратора кластера, данные сначала попадают в опредёленный bucket и лишь затем оказываются на физическом устройстве хранения.
+Каждый bucket в любой момент времени может находиться только в одном репликасете. В то же время, в репликасете может быть несколько bucket'ов, или не быть ни одного. Внутри bucket'а данные задублированы по всем узлам в рамках репликасета в соответствие с фактором репликации.
\ No newline at end of file
diff --git a/docs/index.md b/docs/index.md
index f561ef5d1db3624715ccec4e9dcc4465f0957112..81a9525d61eb2030cd2a3c2c6818d8eed93ad1e6 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -4,7 +4,7 @@ Picodata  — это распределенный сервер приложен
 
 ## Доступные документы и статьи
 
-* Общее описание продукта
+* Общее [описание](description) продукта
 * [Преимущества](benefits) использования Picodata
 * Администрирование БД как [услуга](services)
 * Системные требования
diff --git a/docs/sharding.png b/docs/sharding.png
new file mode 100644
index 0000000000000000000000000000000000000000..b23a8dad1473ebb0a2cce5c3e4ecf909eb6e9389
Binary files /dev/null and b/docs/sharding.png differ