Когда технологии не справляются: как инженеры создают системы для миллионов запросов в секунду

ЭГ: Денис, с чего начинается процесс выбора технологий для таких масштабных задач?

Денис Колпаков: Важно понимать, что инженерные решения редко рождаются из вдохновения. Чаще они возникают из ограничений. Когда система перестает масштабироваться или что-то работает нестабильно, команда вынуждена искать выход. Иногда это приводит к созданию нового инструмента, иногда – к адаптации существующего.

Главное – не просто выбрать технологию, а понять путь, которым к ней пришли: какие гипотезы проверяли, какие отбросили, что поняли о своей архитектуре и ограничениях. Например, при работе с каталогом товаров существующая реализация ограничивала развитие продукта: требовалась быстрая и гибкая фильтрация при высокой динамичности структуры и непредсказуемом порядке фильтров. Это типичная исследовательская задача с высокой степенью неопределенности: ни готовых решений, ни явных референсов.

ЭГ: То есть все начинается с понимания самой проблемы?

Денис Колпаков: Абсолютно. Часто проекты ломаются на этапе постановки цели. Один простой вопрос «А зачем нам это нужно?» может сэкономить недели работы. Недавно мы мигрировали аналитическую систему. Команда планировала восстанавливать часть данных, которых не хватало, но после уточнения выяснилось: эти данные фактически никем не используются. Один вопрос остановил ненужную работу, сэкономив огромный объем ресурсов.

После этого мы фиксируем требования: функциональные (что система должна делать) и нефункциональные (как она должна это делать).

Примеры функциональных требований: обновление данных без сложных релизных процессов; доступ пользователей к актуальной информации; обратная совместимость.

Нефункциональные требования: обработка до 2 млн запросов в минуту; доступность 99,9–99,99%, масштабируемость при росте данных на порядок.

На этом этапе важно расставлять приоритеты: что обязательно, что можно смягчить, а что – проигнорировать. Например, real-time обновления оказалось необязательным: достаточно было обновлений в течение пары часов.

ЭГ: Как команды проверяют готовые решения, чтобы не тратить месяцы на разработку с нуля?

Денис Колпаков: Сначала составляем короткий шорт-лист инструментов – обычно 3–5 кандидатов. В нашем случае это были Postgres, Sphinx, Neo4j, Redis и SQLite. Начинаем с технологий, где есть экспертиза, затем популярные решения, и только потом – нестандартные варианты.

Для всех кандидатов применяем одинаковый набор тестов: одни и те же данные, сценарии, метрики – скорость отклика, стабильность, ресурсы. И обязательно формулируем kill-criteria: если инструмент не улучшает ключевые показатели в рамках ограниченных ресурсов – отбрасываем. Это защищает команду от бесконечного «дотягивания» решения до идеала.

ЭГ: А как определить момент, когда готовые инструменты не подходят и нужно разрабатывать собственное решение?

Денис Колпаков: Критерий простой: если за заданные итерации инструмент не показывает прогресса по ключевым метрикам, значит, он не подходит. Например, при тестировании каталога мы дали каждому инструменту два спринта, максимум две итерации. Если улучшений нет – движемся дальше.

Важно понимать: «не подходит» не значит «плохой». Решение может быть отличным, но не вписываться в контекст по скорости, стоимости или масштабируемости. После этого мы принимаем осознанное решение о создании собственного решения – уже с полным пониманием ограничений, метрик и стоимости.

ЭГ: Какие ошибки чаще всего допускают команды на пути к решению?

Денис Колпаков: Главная ошибка – не проверять цель. Команда начинает решать проблему, которая фактически не существует или не нужна. Вторая – игнорировать существующие подходы. Многие переоценивают уникальность своей задачи и стартуют с нуля, хотя аналоги есть – в компании или в индустрии.

Результат: месяцы переработки, рост стоимости, технический долг. Даже когда создаешь собственное решение, проверка готовых инструментов не проходит даром: команда уже понимает специфику задачи, ограничения и компромиссы.

ЭГ: Как строится процесс экспериментов и тестирования инструментов?

Денис Колпаков: Сначала ограничиваем эксперимент рамками: время, доступная экспертиза, команда. Формируем шорт-лист инструментов, задаем таймбоксы на каждый.

Далее создаем единый пул экспериментов: одни и те же сценарии, данные и метрики для всех инструментов. Устанавливаем kill-критерии. Это позволяет избежать бесконечного перебора и сосредоточиться на достижении конкретного результата.

Важно понимать: лучше упустить идеальное решение, чем тратить месяцы на его поиск. На практике мы проверяли Postgres, Sphinx, Redis, Neo4j, SQLite и другие. Возможно, упустили что-то, но за счет серии экспериментов выработали подход, который давал баланс между скоростью, стоимостью и функциональностью.

ЭГ: Какие советы вы могли бы дать инженерам, которые впервые сталкиваются с исследовательскими задачами?

Денис Колпаков: Системный подход – ключ. Определяйте цель и требования, расставляйте приоритеты, делайте proof of concept, задавайте таймбоксы и критерии остановки.

Не бойтесь задавать вопросы и пересматривать очевидное. Даже маленькая проверка гипотезы может сэкономить недели работы. И главное: инженерная работа – это не только технологии, но умение принимать решения в условиях ограничений и видеть баланс между скоростью, качеством и стоимостью. Именно это отличает рутинного разработчика от инженера, способного решать задачи на миллионы запросов в секунду.

Василий Черный

*Организация запрещена на территории РФ

*включен Минюстом РФ в список физлиц-иноагентов