diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..62c8935
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+.idea/
\ No newline at end of file
diff --git a/case_study.md b/case_study.md
new file mode 100644
index 0000000..6c78db8
--- /dev/null
+++ b/case_study.md
@@ -0,0 +1,40 @@
+# Домашнее задание 8
+
+## Немного о себе
+
+Текущий рабочий проект - это 3commas.io. Высоконагруженое приложение с репликацией данных, огромным количеством джоб sidekiq и крутой командой разработчиков. 
+Насколько я могу судить с перфомансом все достаточно неплохо, но есть проблемы в том, что очень много всего лежит в монолите, в связи с этим сейчас идет курс на то, чтобы немного распилить монолит и вынести из него в отдельные сервисы определенные части логики.
+
+Я работаю в команде RND, делаем MVP всяких экспериментальных фич, типо новых торговых ботов, маркетплейса для приложений сторонних разработчиков.
+
+К сожалению немного успел до конца курса сделать, но есть несколько кейсов, о которых можно расскзаать.
+
+### "Жирный N+1 в API"
+
+Использовал Scout, чтобы найти точки роста. В этой системе мониторинга очень удобно, что показывается N+1 проблемы.
+Заметил, что на первом месте в API ендпоинт, в котором делается N+1 запросов в базу, а именно к ActiveStorage::Attachments.
+Взял на себя устранить эту проблему, хотя наяпрмую к моей команде это не относилось. Сделал подгрузку картинок с помощью хелпера `with_attached_smth` и выкатили на прод.
+В итоге ендпоинт пропал из раздела N+1 в Scout.
+
+
+### "Устаревший флоу"
+
+В процессе прохождения курса много узнал о разных системах монитринга, в том числе связка Prometheus + Grafana (они у нас всегда были в проекте, но я не знал как этим пользоваться).
+Заметил в процессе блуждания по графане странные пики нагрузки на пуму продакшена.
+Выяснил, что это за ендпоинт. Оказалось, что в этот ендпоинт наш же внутренний сервис делал вебхуки, причем делал их пиками до 15к в минуту.
+Посоветовавшись с коллегами, пришли к выводу, что такой флоу жил со времен, когда у нас еще не было Kafka, а сейчас как раз можно переделать взаимодействие на нее.
+Взялся за эту задачу (заодно это был мой первый опыт с работой с кафкой). Перевел флоу на Kafka, нагрузка на ендпоинт по понятным причинам свелась к 0.
+
+### Защита от деградации
+
+Написал тесты для своего текущего рабочего проекта, чтобы избежать N+1 на всех ендпоинтах, где это возможно.
+
+
+### Оптимизация задачи по расписанию
+
+Необходимо было доставать информацию по примерно 150к аккантов из внешнего сервиса.
+Использовал `bulk_insert` для записи в базу. Использовал функциональный индекс, для запросов, которые проверяют есть ли у нас уже такие сущности.
+Потом по статистике в pg_hero понял, что этого все-таки недостаточно и немного переосмыслил код таким образом, что сократил запросы к базе(таблице с 80kk записей) в 13 раз. Для этого достаточно сначала сходить во внешний сервис, потому что у большинства аккаунтов там нечего получать и тогда уже и в базу идти не нужно, чтобы достать последнюю сущность которую мы выгрузили в прошлый раз(потому что ее там и не будет)
+
+
+Пока это все, что могу расскзаать, но дальше больше! Буду стараться применять знания полученные в курсе на своем текущем месте работы!