85 000 пользователей: как мы столкнулись с ограничениями собственной архитектуры

Команда корпоративной почты Mailion была уверена, что архитектура спокойно выдержит 85 000 пользователей: Go быстрый, MongoDB тянет, функционал стабильный. Но реальная нагрузка пришла раньше, чем мы успели «оптимизировать потом», — и буквально размазала все наши предположения. 
Выяснилось, что MongoDB стала главным тормозом, утечки памяти прятались в тех местах, которые считались самыми безопасными, сеть была перегружена избыточными взаимодействиями, а единая точка управления объектами оказалась идеальным архитектурным антипаттерном, который с ростом пользователей нагружал всю систему.
Этот доклад — честная анатомия наших ошибок и переоптимизаций, рассказ о том, как мы сами устроили себе архитектурный ад, как выбирались из него и какие выводы сделали. Если вы хоть раз думали «потом оптимизируем» — приходите посмотреть, как выглядит это самое «потом» на реальных метриках, графиках и живом продакшене.
В докладе — честная история о том, что пошло не так и как мы это исправляли.
Вы узнаете:
как pprof помогал локализовать узкие места;
почему MongoDB стала бутылочным горлышком;
как мы нашли и устранили утечки памяти;
каким образом избыточные сетевые взаимодействия замедляли всю систему;
и как единая точка управления объектами создала неожиданный каскад проблем.
Главный вывод: откладывать производительность «на потом» нельзя. Мы поделимся конкретными инструментами, метриками и решениями, которые помогут добиться устойчивых 85 000 пользователей (или больше) без жертв в функциональности.