Fury: как за четыре месяца разработки собственного мессенджера не выгореть и довести проект до ума
В какой‑то момент, наблюдая, как один за другим то блокируются, то ограничиваются привычные мессенджеры, я поймал себя на простой мысли: хватит зависеть от чужих решений, пора написать свой инструмент общения. План был максимально приземлённый - закрыть личные задачи: связь с родными, коллегами, партнёрами по бизнесу. Небольшое приложение "для своих", ничего больше.
Реальность быстро показала, насколько наивными были эти ожидания. Всего за четыре месяца "домашний" проект превратился в вполне живой мессенджер с собственной аудиторией, пользовательскими сценариями, неожиданными нагрузками и постоянной гонкой между разработкой фич и борьбой со взрывающейся инфраструктурой.
Первые пользователи и естественные стресс‑тесты
Самое удивительное случилось довольно рано: в системе стали появляться люди, которых я вообще не знал. Регистрации пошли каждый день, и приложение перестало быть "семейной игрушкой". Это дало два эффекта:
1. Появился честный фидбэк - пользователи начали сообщать о неудобствах, просить новые функции, рассказывать, что ломается.
2. Любое "узкое место" моментально всплывало на поверхность - нагрузка на сервер, работа уведомлений, хранение медиа, стабильность соединений.
То, что раньше казалось второстепенным, внезапно стало критически важным. Например, групповые чаты. Изначально я отнёсся к ним как к чём‑то второстепенному: простая переписка нескольких людей, без изысков. Но в реальной эксплуатации именно группы стали основным драйвером нагрузки и источником сложностей.
Группы: от примитивных чатов к полноценным сообществам
Первыми под нож рефакторинга логично попали группы. Пришлось срочно наводить порядок:
- Система модерации. Появилась полноценная панель управления участниками: назначение админов, ограничения по отправке сообщений, блокировки нарушителей. Без этого в активных чатах мгновенно начинался хаос.
- "Режим канала". Очень быстро стало понятно, что многим нужна не беседа, а односторонний формат - автор пишет, остальные читают. Так родился режим канала: по сути, та же группа, но сообщения может публиковать только владелец или доверенные лица, а интерфейс оформлен в виде удобной ленты.
Такая трансформация позволила использовать Fury не только для диалогов, но и как площадку для новостей, объявлений, тематических рассылок.
Боль мегабайтов: как не убить память смартфона
Особенность архитектуры Fury - упор на локальное хранение. Сервер держит файлы минимальное время, ровно столько, чтобы передать их адресатам, а вся история и медиа в итоге оседают в памяти телефона. На бумаге это выглядело разумно: экономия серверных ресурсов и большая приватность.
На практике всё оказалось суровее. Достаточно двух‑трёх любителей "пошуметь" в группе - с видосами, гифками, мемами, - и за одну‑две недели объём данных в таком чате спокойно переваливает за гигабайт. Приложение у меня на телефоне однажды раздулось до более чем 2 ГБ. Смотреть на это было физически больно.
Пришлось точечно вмешиваться:
1. Раздел "Данные и память".
Я добавил детальную статистику: сколько места занимает каждый чат, сколько файлов внутри, какие именно группы превращаются в цифровую свалку. Это сразу дало понимание, где проблема.
2. Ручная очистка.
Появились кнопки: сначала "удалить файлы старше 30 дней", потом - "удалить всё", позднее - "удалить старше 7 дней". Это помогло продвинутым пользователям, но большинство, как водится, в эти настройки просто не заходят.
3. Автоматическое ограничение по размеру.
В итоге я внедрил систему авточистки на основе лимита по объёму. По умолчанию для публичных групп выставляется порог в 200 МБ, который админ может изменить или отключить. При его достижении старые файлы начинают удаляться автоматически.
Такое решение спасает телефон обычного пользователя от незаметного превращения в кладбище медиафайлов и снижает количество жалоб на "приложение, которое жрёт всю память".
API и система экстренных уведомлений
Параллельно я начал собирать botApi. Отношение к этой идее у меня до сих пор противоречивое: сейчас в Fury достаточно "живое", человеческое общение без навязчивых ботов и "умных" ассистентов. Не хотелось ломать эту ламповость.
Но один важный сценарий всё‑таки подтолкнул к развитию API. В нескольких регионах для меня критична оперативная информация об угрозах БПЛА и других опасных событиях. Поэтому на базе API была реализована система каналов экстренного оповещения:
- специализированные каналы внутри Fury для конкретных регионов (например, для южных областей);
- внешний анализ профильных источников с автоматической пересылкой важной информации в соответствующие каналы мессенджера;
- минимальная задержка между появлением события и уведомлением пользователей.
Так API сразу нашёл "правильное" применение - не для спама и игр, а для того, чтобы реально помогать в критических ситуациях.
Рекомендации: задел под монетизацию
Раздел "Рекомендации" стал первым шагом к потенциальной коммерциализации. Пока это единственное место, где видно список продвигаемых каналов.
Я вручную отбираю туда действительно интересные и полезные площадки - то, за что самому не стыдно. Пользователи активно переходят в рекомендованные чаты, читают, подписываются. В будущем это может перерасти в аккуратную модель монетизации без агрессивной рекламы:
- платное размещение в рекомендациях для каналов с качественным контентом;
- специальные подборки по тематикам;
- приоритетное продвижение локальных каналов для конкретных регионов.
Главное - не превратить раздел в "баннерную помойку" и сохранить доверие аудитории.
Голосовые звонки: HD‑качество на нестабильных сетях
Огромный пласт работы ушёл на отладку звонков. Оказалось, что реализовать действительно качественную голосовую связь - это отдельный продукт внутри продукта.
Внутри Fury с нуля были сделаны:
- собственные алгоритмы поверх UDP и P2P‑соединений;
- коррекция потерь пакетов;
- адаптивный jitter‑буфер с изменяемой скоростью воспроизведения - чтобы голос оставался в "точке актуальности" даже при просадках сети;
- оптимизация кодеков под работу в стеснённых условиях по трафику.
Сейчас могу уверенно сказать: в Fury можно разговаривать часами, получая HD‑звук и при этом не выжигая гигабайты мобильного трафика. Алгоритмы сглаживания отлично держат удар даже там, где сеть откровенно "сыпется".
Базовый протокол взаимодействия между клиентом и сервером - тоже собственная разработка, по уровню сопоставимая с TCP‑стеком. Ни WebSocket, ни HTTPS в качестве основного транспорта не используются - только "сырые" TCP/UDP‑соединения и своя логика поверх них. Это сложнее в реализации, но даёт полный контроль над поведением протокола и его оптимизацией под конкретные задачи мессенджера.
Проведённый аудит безопасности протокола с помощью анализа исходного кода и специализированных инструментов показал обнадёживающие результаты: критичных уязвимостей не выявлено, архитектура в целом выдерживает довольно жёсткую проверку на типичные ошибки реализации сетевых протоколов и авторизации.
Видео: желаемое и возможное
Многие логично спрашивают о видеосвязи. Но здесь всё заметно сложнее. Если честно, даже с голосом путь к стабильному и чистому звуку был далёк от тривиального решения. Видео - это совсем другой уровень компромиссов:
- больше трафика и выше требования к пропускной способности;
- проблемы с задержками, разницей частот кадров, адаптацией под слабые устройства;
- необходимость балансировать между качеством картинки и стабильностью потока.
Сейчас видеозвонки находятся в "планах на будущее", но реализовывать их вслепую, лишь бы "галочка была", точно не хочется. Если и делать - то так, чтобы это не ломало остальной опыт использования и не превратилось в источник постоянных багов.
Backend: эволюция от монолита к микросервисам
Бэкенд изначально представлял собой классический монолит: один сервис на Go, база данных MySQL, один исполняемый файл, который отвечал буквально за всё - от регистрации пользователей до обработки звонков и доставки файлов.
Пока пользователей было немного, это работало. Но по мере роста стало ясно: любой сбой в одной части кода валит весь сервис целиком, обновления превращаются в акцию с повышенным уровнем адреналина, а горизонтально масштабировать такую конструкцию крайне неудобно.
Постепенно начался переход к микросервисной архитектуре:
- вынесены в отдельные сервисы авторизация, доставка сообщений, хранение медиа, обработка звонков;
- введены очереди и брокеры сообщений для асинхронных задач;
- разные компоненты получили возможность масштабироваться независимо друг от друга.
Такой подход потребовал серьёзной переписки кода и пересмотра многих решений, но в обмен дал устойчивость к нагрузкам и возможность "по частям" обновлять систему без глобальных падений.
Как не сойти с ума в одиночной разработке
Техническая часть - только половина истории. Другая половина - психологическая. Делать мессенджер одному, с нуля, за ограниченное время - хороший рецепт выгорания, если не выстроить правила игры.
То, что мне помогло:
- Жёсткий приоритет. Я перестал гнаться за количеством фич. На каждый запрос пользователей задавался вопрос: это критично или можно отложить? Так появилось понимание ядра продукта.
- Короткие циклы. Вместо "идеального релиза" - частые небольшие обновления. Это даёт ощущение прогресса и быстрое закрытие багов.
- Ограничения по времени. Я поставил себе правило: не кодить до полуночи, как бы ни хотелось "доделать ещё одну мелочь". Сон и голова дороже любой фичи.
- Фокус на стабильности. Лучше одна новая функция без падений и утечек памяти, чем пять "сырых" возможностей, которые ломают опыт пользователя.
Организация разработки: инструменты и подходы
Чтобы не захлебнуться в задачах, пришлось быстро выработать дисциплину:
- вести список задач по блокам: backend, клиент, дизайн, инфраструктура;
- отмечать не только "что сделать", но и "что не делать" - это помогает отсекать лишнее;
- автоматизировать рутинное: сборки, выкатывание, базовые тесты;
- логировать всё, что может пригодиться при разборе инцидентов - от ошибок протокола до статистики по памяти.
При такой нагрузке любая ручная операция, повторяемая десятки раз, неизбежно превращается в источник ошибок и усталости. Автоматизация - не роскошь, а способ сохранить голову холодной.
Пользовательский опыт как главный критерий успеха
Очень легко увлечься технологической стороной: собственные протоколы, низкоуровневый TCP/UDP, микросервисы. Но в конечном счёте пользователю безразлично, какой код крутится на сервере. Его волнует другое:
- быстро ли приходят сообщения;
- удобно ли искать чаты и людей;
- не забивает ли приложение память и батарею;
- слышит ли он собеседника без хрипов и обрывов.
Каждое решение в Fury рано или поздно приходилось проверять через эту призму. Если фича сложная, но не даёт заметного прироста удобства - её место в бэклоге, а не в срочном релизе.
Что дальше
Четыре месяца интенсивной разработки превратили небольшой личный эксперимент в живой продукт с аудиторией, стабильной голосовой связью, системой групп и каналов, рекомендациями и относительно гибкой бэкенд‑архитектурой.
Впереди - доработка API, возможный выход в сторону видеосвязи, расширение инструментов для администраторов групп, улучшение систем безопасности и приватности, настройка аккуратной монетизации через рекомендации.
Главный вывод за это время: создать мессенджер с нуля - тяжело, но реально. Критично другое - вовремя останавливать себя, отбрасывать лишнее, следить за тем, чтобы технические амбиции не разрушили психику, а пользователи не стали невольными бета‑тестерами вечного прототипа.
