# 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?
  - Предполагается ли хранение или обработка персональных данных?
 
- **Метрики**

Соберите список ключевых бизнесовых, продуктовых и технических метрик.