Разработка мобильного приложения для петиций под ключ

Мобильное приложение для петиций: где ломается сбор подписей

Петиция живёт ровно один всплеск: публикация у крупного автора, упоминание у медиа, репост в сообществе. За минуту в мобильное приложение для петиций приходит столько запросов, сколько оно видело за сутки. Если подпись записывается синхронно с внешней проверкой номера, почты или антибота, очередь растёт, время ответа перерастает ожидание в интерфейсе — и человек видит ошибку. Повторять он не станет: закрыл и забыл.

Так и выглядит потеря подписей при пиковой нагрузке. Внешний сервис может отвечать медленно, отдавать отказ или посчитать один запрос дважды — и тогда сбор подписей онлайн либо встаёт, либо наполняется дублями. Отдельная беда — целостность профилей: один человек подписывает с телефона и планшета, старый аккаунт привязан к прежнему номеру, вход по почте и по телефону создают две записи. Голос учитывается дважды, и кампания получает не поддержку, а публичный спор о накрутке.

Следом зависает модерация петиций. Пока проверка ручная, поток в пике копится в очереди, авторы ждут ответа сутками, часть обращений уходит в отказ по формальным признакам. Крупные площадки вроде Change.org живут с этим годами, но и там спорные случаи разбирают люди — автоматика закрывает только однотипные.

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

Что меняется после внедрения: четыре измеримых эффекта

Доля подтверждённых подписей

Подпись фиксируется только после двух шагов: сам акт в интерфейсе и подтверждение владельца — по коду в сообщении или из связки с учётной записью. Дедупликация идёт по устойчивому идентификатору устройства и контакту, поэтому повторное нажатие не создаёт вторую запись в реестре. Вместо ручной чистки «сырых» голосов в базе сразу лежат валидные — доля подтверждённых подписей перестаёт быть предметом спора с проверяющими.

Время реакции на пик

Кампания в соцсетях приводит тысячи людей за минуты, и именно здесь обычные сборки ломаются. Подписные сервисы масштабируются по нагрузке горизонтально, а запись идёт через очередь: пик не роняет форму, а разбирается по мере обработки, без потери нажатий. Инженерный смысл — форма отвечает за доли секунды даже на порядок выше привычного трафика.

Время восстановления после сбоя

Схема с репликой и регулярными резервными копиями позволяет вернуть сервис за минуты, а не за часы простоя. Регламент отката на предыдущую сборку отработан заранее: если релиз ведёт себя не так, версия откатывается целиком, данные подтверждённых подписей остаются целы. Уведомления о статусе петиции уходят через Firebase — доставка не зависит от того, на каком узле в этот момент работает сервис.

Исчезнувший класс отказов

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

Все четыре эффекта проверяются на приёмочных испытаниях до запуска: мы подаём пиковую нагрузку, обрываем соединение и откатываем релиз.

Форматы реализации: нативный код, единая база, веб-оболочка

Формат сборки определяет, как приложение для петиций ведёт себя в поле: принимает подпись при слабой связи, встраивается в камеру и биометрию, и какова стоимость поддержки приложения на горизонте нескольких лет. Ниже — три рабочие альтернативы, между которыми выбирают на старте, без ярлыков «лучше/хуже».

Три варианта под задачу сбора подписей

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

Формат фиксируем до старта работ — смена на середине означает переписывание слоя подписи и повторную проверку на обеих платформах.

Как идёт внедрение: шесть этапов от схемы до приёмки

Сбор подписей устроен сложнее, чем форма с кнопкой: одна подпись — это одно подтверждённое действие одного человека, и подтверждаемость важнее красивых экранов. Поэтому мы ведём внедрение фиксированной последовательностью — от аудита того, как подписи собираются сейчас, до передачи проекта с доступом и документацией. Ниже порядок работ, по которому видно, на каком шаге какой риск закрывается.

1. Аудит текущего сбора подписей. Разбираем, как процесс идёт сегодня: бумажные бланки, таблицы, почтовые подтверждения. Фиксируем, где теряются записи, кто и как проверяет дубли, какие требования к юридической значимости нужно сохранить.
2. Аудит схемы данных. Описываем сущности — кампания, подпись, подтверждение личности, журнал действий — и правила дедупликации. Проверяем, что схема выдержит рост числа кампаний и выгрузки для проверяющих.
3. Проектирование приложения. Сценарий подписи, подтверждение, офлайн-режим при слабой связи, уведомления, административная часть для модерации и экспорта подписных листов.
4. Настройка и сборка. Реализуем согласованную схему, подключаем хранилище и очередь обработки, настраиваем роли операторов и журналирование каждого изменения записи.
5. Проверка под нагрузкой. Прогоняем пиковый сценарий кампании: одновременные подписи, дедупликация на потоке, обрыв связи в момент записи. Смотрим долю успешно сохранённых подписей и корректность отката.
6. Приёмка и передача проекта заказчику. Проверяем по сценариям из согласованного перечня, затем отдаём доступы, конфигурации, схему данных и инструкции для операторов.

После передачи у вас остаётся рабочая система и понятная документация, а не закрытый ящик: сопровождение, доработки и обновления обсуждаем отдельно, когда состав работ ясен. Опишите задачу — вернёмся с оценкой и планом по этим этапам.

Что передаём на руки: схемы, доступы, регламенты модерации

Передаём не архив файлов, а рабочий комплект: по каждому артефакту понятно, кто владелец, как его обновлять и что делать при сбое. Аккаунты магазинов приложений, серверные ключи и панель рассылок оформляем на ваши реквизиты с двухфакторной защитой — доступ не остаётся привязан к подрядчику.

• Схема данных подписей. Структура записи о подписи, связь с кампанией и учётной записью, уникальный ключ против повторной подписи, журнал изменений. Результат сбора проверяется по выгрузке, а не по счётчику в интерфейсе.
• Матрица ролей доступа. «Роль → действие»: гость, подписант, модератор, администратор кампании, владелец. Отдельно прописано, кто видит персональные данные, а кто только счётчики и статистику.
• Регламент модерации. Что публикуется и что отклоняется, сроки рассмотрения, порядок апелляции для автора петиции, эскалация спорных случаев.
• Инструкция для модераторов. Разбор очереди по шагам, критерии отклонения, шаблоны ответов авторам, действия при жалобах и массовых однотипных подписях.
• Документация на приложение. Сборка и выпуск, конфигурация окружений, схема интеграций, порядок правки правил модерации без выпуска новой версии.
• План выпуска обновлений. Порядок проверки перед публикацией, условия отката на предыдущую версию, ответственный за дежурство после релиза.

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

Что было до изменений

Публикация кампании давала всплеск в 15–20 раз от обычного потока. Приложение держало ровный трафик, но на пике запись подписи вставала в очередь: часть сессий заканчивалась ошибкой, человек нажимал кнопку повторно и создавал дубль, который потом сводили вручную. По логам до изменений около 8% сессий в момент публикации теряли подтверждение, подача подписи занимала в среднем 4 секунды, а разбор отклонения — 3–4 часа ручной работы дежурного.

Что поменяли в схеме и что стало

Разнесли чтение и запись: витрина кампаний читается из кэша, а подпись уходит через очередь с подтверждением — пользователь видит статус, а не таймаут. Ввели идемпотентность по паре «сессия + кампания», поэтому повторный тап не создаёт вторую запись, а подхватывает уже поставленную. Масштабирование перевели на Kubernetes: число реплик растёт от длины очереди, а не от загрузки процессора, — реакция начинается раньше, чем посетитель почувствует задержку. Реестр подписей вынесли на реплики чтения, справочник активных кампаний прогреваем до публикации.

Доля потерянных подтверждений на пике — 0,2% вместо 8%, подача подписи — 0,6 секунды вместо 4. Реакция на отклонение по автоматическому оповещению сократилась с трёх часов до 12 минут, при этом объём реестра вырос втрое. Схема держит следующий пик без ручного вмешательства инженеров — тот же запас работает на кампаниях, которые выходят одна за другой.

Чем платформа для сбора подписей отличается от формы на сайте?

Веб-форма и приложение для сбора подписей закрывают разные отрезки одного процесса. Форма на сайте — точка входа: человек пришёл по ссылке из поиска, подписал за минуту, ничего устанавливать не нужно. Мобильное приложение берёт на себя то, что браузер не тянет: офлайн-сбор, подтверждение личности и напоминания.

Разница проявляется на подтверждении личности. В сбор подписей на сайте опора — код из сообщения или письмо, и один человек с двумя адресами оставит две записи. В приложении проверка проходит один раз и закрепляется за устройством, а каждая новая подпись сверяется с уже сохранённым идентификатором — повторная отсекается до записи.

Офлайн-сбор — то, чего веб-форма не умеет в принципе. Приложение складывает подпись в локальное хранилище вместе со временем и меткой места, а при появлении сети отправляет накопленное по очереди. Сборщик с планшетом работает в зале без связи, и данные не теряются при повторной отправке.

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

Частые вопросы по модерации и петициям: разбираем сомнения

Модерация петиций и защита от накрутки подписей — две темы, из-за которых запуск чаще всего откладывают. Ниже пять сомнений, которые всплывают на этапе оценки, и то, как каждое из них закрывается инженерно.

Что произойдёт с уже собранными подписями при миграции?

База переносится порциями, каждая пачка сверяется по контрольной сумме, дубли схлопываются по ключу «кампания + подписант». Переключение идёт на чтение с новой базы, старая остаётся в реплике до конца сверки. Откат — одна команда, и он доступен в любой момент, пока расхождение не равно нулю.

Выдержит ли приложение пик во время громкой кампании?

Подписи пишутся асинхронно через очередь, экран подтверждения отдаётся сразу и не ждёт ответа базы. Счётчики и списки кэшируются, поэтому всплеск на одном экране не роняет остальные разделы. Счётчик пересобирается с задержкой в несколько секунд — это осознанный размен точности на устойчивость.

Что входит в поддержку приложения после запуска?

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

Кому принадлежат собранные подписи?

База и выгрузки остаются на вашей стороне, у нас — доступ только на время работ. Экспорт в таблицу или через программный интерфейс открыт в любой момент, включая кампании, которые ещё идут. После передачи доступы закрываются, а ключи отзываются.

Обсудим задачу: что прислать для точной оценки

Чтобы оценка разработки приложения опиралась на факты, а не на догадки, достаточно нескольких входных материалов. Чем конкретнее вводные, тем меньше допущений в расчёте сроков и тем реалистичнее план внедрения по этапам — от проверки подписи до выгрузки подписей в адрес получателя. Присылайте то, что уже есть, остальное уточним вопросами на созвоне.

• Сценарии подписанта и автора петиции: создание, модерация, сбор подписей, передача адресату.
• Правила проверки подписи: как подтверждается уникальность человека и какие данные остаются в системе.
• Роли и права: модератор, представитель ведомства, поддержка, доступ к статистике и выгрузкам.
• Интеграции: внешние реестры, карты, уведомления, аналитика, официальные ответы и отчётность.
• Если решение уже работает — аудит текущего решения: узкие места, отказоустойчивость, нагрузка на поддержку.
• Референсы и дизайн: брендбук, примеры интерфейсов, требования к доступности для слабовидящих.
• Требования к хранению персональных данных, регион размещения серверов и срок хранения истории.
• Приоритеты по этапам: что должно попасть в первый релиз, а что можно отложить без потери смысла.

Опишите задачу в свободной форме и приложите то, что уже готово. Мы вернёмся с оценкой объёма работ, планом внедрения, составом команды и перечнем рисков по срокам и данным.