Finish analytics case

* Start working on health_app case

Author: Nurchik

cases/analytics.md

@@ -0,0 +1,33 @@
+## Описание кейса
+Создать бэкенд который принимает 1_000_000 запросов (аналитика) в минуту и должен выдавать отчеты и статистику (аналитика) и давать данные ML-модели.
+## Задача
+1. Запись в БД должна проходить очень быстро (<=10ms)
+2. Данные необязательно должны быть персистентными
+3. Данные можно хранить без индексации
+4. Должны поддерживаться инкрементальные обновления данных на основе статистики
+
+## На что обращаем внимание
+1. Знаком ли с sharding и репликацией БД
+2. Знаком ли с колоночными БД
+3. Знаком ли с Data Lake, OLAP
+4. Знаком ли с решениями по потоковой обработке данных - Apache Spark, Apache Airflow
+5. Знаком ли с брокерами сообщений - Apache Kafka, RabbitMQ
+6. Знаком ли кандидат с паттернами realtime и batched - обработки данных
+7. Знаком ли кандидат с window-функциями (partition by, etc.)
+8. Знаком ли кандидат с подходами построения кластера БД - Multi-Master, Primary-Secondary, writes only on primary - reads only on secondary
+
+## Пояснения
+1. Почти нереально записывать в СУБД <=10ms потому что может быть сетевой latency, кластер может развалиться и т.д.
+2. Можно использовать redis - что нам даст O(1) на insert
+3. СУБД дороже в плане инсертов, чем складирование в файлы или в memcache (redis, memcached)
+4. Горизонтальное масштабирование (для потоковой обработки) требует детального планирования:
+    * как именно будем дробить задачу
+    * как разбираться с падениями воркеров (идемпотентность)
+    * как мониторить работу воркеров
+5. Кандидат должен спросить нужно ли гарантировать уникальность записей в БД?
+6. Для поддержки инкрементальных обновлений чаще всего необходимо поднимать отдельный инстанс БД, в котором будет храниться статистика (которая обновлеяется реже чем аналитические запросы будут приходить). Отдельный инстанс не будет испытывать нагрузки, в отличие от БД в которую записываются аналитические запросы.
+
+
+Есть аналитика, которая шлет 100500 запросов в бек. Бек должен писать в данные в базу, как-то отдавать ML и строить пользовательскую историю.
+
+Проблема в том, что бек принимает запросы и долго пишет в базу. Как можно решить проблему?

cases/draft_analytics.md

@@ -1,4 +1,4 @@
-Задача
+## Описание задачи
 We need to build a SaaS product in a healthcare sector, which helps users track their sleep.
 So, we need 2 applications for users to work with:
 * Mobile App
@@ -8,7 +8,19 @@ Mobile app should collect data about user's sleep (duration, movement, sounds, e
 * Preparing stats and analytics
 * Also, Mobile App and Web App should display analytics and stats to users.
 
-На что обращаем внимание:
-1. Умеет ли кандидат с ML-моделями (training, inference)
-2. Знает ли про очереди сообщений
+## Задача
+1. 
+
+## На что обращаем внимание:
+1. Умеет ли кандидат работать с ML-моделями (training, inference)
+2. Знает ли про очереди сообщений - Kafka, RabbitMQ, redis
 3. Сталкивался ли с batch/streaming data processing (Apache Spark, Apache Airflow, etc.)
+4. Знает ли про объектные хранилища - S3
+5. Как кандидат будет делать балансировку нагрузки и как подойдет к масштабированию?
+6. Знаком ли кандидат с распределенными вычислениями и оркестрацией (для кейсов когда нужно чейнить несколько сервисов - saga и т.д.)
+
+## Пояснения
+1. Лучше статику сразу хранить в s3, потому что огромный массив данных в БД будет тормозить запросы, миграции, бэкапы и т.д.
+2. Т.к. МЛ-моделька работать будет не быстро, то всё равно нужно добавлять очереди сообщений, чтобы балансировать нагрузку между воркерами (несколько инстансов МЛ-моделей) и отдавать результаты по мере их готовности (event-driven архитектура)
+3. Можно также использовать websocket-ы чтобы не тащить очереди сообщений, но тогда необходимо балансировку нагрузки выносить в отдельный сервис
+4.