diff --git a/tech_design_review.md b/tech_design_review.md
index 648332d..6438bc8 100644
--- a/tech_design_review.md
+++ b/tech_design_review.md
@@ -1,7 +1,79 @@
 # Tech design Review в Авито
 
 ## Что такое TDR
+Tech Design Review — это процесс описания изменений в дизайне, архитектуре, сервисе или продукте и запрашивания фидбэка у коллег-разработчиков. Похож на ревью Pull Request.
+
 ## Жизненный цикл TDR
+Процесс TDR строится по такому алгоритму:
+- Формулирование проблемы.
+- Создание дашборда для TDR.
+- Создание дизайн-документа.
+- Начало ревью.
+- Сбор оценок и отзывов.
+
+После этого начинается доработка продукта по фидбэку, и ревью проводится заново. Если доработок больше нет, можно приступать к реализации.
+
 ## Когда стоит делать TDR
-## Что нужно, чтобы начать
+Мы рекомендуем проводить TDR в следующих случаях:
+- **Портфельный продукт.** Если продукт находится в продуктовом портфеле, то до наступления Gate 2 должен быть проведен TDR.
+- **Высокий уровень влияния.** Если решение затрагивает более одного юнита, то обязательно проведение ревью и участие в нём представителей от юнитов.
+- **Значительные инвестиции в разработку.** Если суммарно нужно потратить больше 3 челеловек в месяц на работу по задаче.
+- **Возрастание тех. долга.** Если разрабатываемое решение (например, MVP) может значительно увеличить тех. долг.
+- **Передача сервиса или модуля в другую команду.** Коллегам будет легче поддерживать и развивать решение, если обсудить его архитектуру в формате TDR.
+- **Внедрение новой технологии/продукта.** Рассмотренные причины внедрения, альтернативы, будет обоснование и согласованно с архитектурой.
+
 ## Шаблон TDR
+Для проведения TDR нужно создать дизайн-документ. У всех дизайн-документов единая структура.
+
+- **Проблема**
+
+Опишите, какая проблема с точки зрения продукта или бизнеса решается предлагаемым изменением.
+
+- **Описание**
+
+Опишите, что вы планируете сделать и как это будет работать на решение описанной выше проблемы.
+
+- **Схема зависимостей**
+
+Создайте схему зависимостей и прикрепите её в дизайн-документ.
+
+- **Компромиссы**
+
+Опишите, на какие компромиссы в решении мы идём и почему, опишите планируемый тех.долг, когда и как он будет устранён.
+
+- **Альтернативы**
+
+Если рассматривались какие-то альтернативы, зафиксируйте их здесь.
+
+- **FAQ**
+
+В этой секции фиксируются вопросы, которые возникают в процессе проектирования и ответы на них.
+
+- **Нагрузка:** в этом блоке собран список вопросов, на которые нужно ответить и сделать описание расчёта.
+  - Какая нагрузка в RPM ожидается на сервис?
+  - Какое количество реплик нужно на каждый DC?
+  - Отношение нагрузки на чтение и запись.
+ 
+- **Ресурсы:** в этом блоке собран список вопросов, на которые нужно ответить.
+  - Есть ли похожие по потреблению ресурсов сервисы? Если да, то сколько они потребляют?
+  - Закладывались ли ресурсы под этот сервис во время планирования ресурсов?
+  - Если нужна база данных, какую конфигурацию вы выбрали?
+  - Нужно ли хранилище на ceph для этого сервиса?
+  - Нужны ли специфичные ресурсы: например, GPU?
+  - Нужно ли хранить дополнительные поля в айтеме?
+  - Нужно ли хранить картинки или файлы?
+ 
+- **Структура баз данных**
+
+Опишите структуру базы данных и планируемый способ хранения.
+
+- **Информационная безопасность:** обсудите ответы на эти вопросы с безопасниками и покажите им результаты моделированя угроз.
+  - Предполагает ли решение добавление публичного API?
+  - Предполагается ли хранение или обработка персональных данных?
+ 
+- **Метрики**
+
+Соберите список ключевых бизнесовых, продуктовых и технических метрик.
+
+
+