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

Мобільний застосунок для петицій: де ламається збір підписів

Петиція живе рівно один сплеск: публікація у великого автора, згадка в медіа, репост у спільноті. За хвилину в мобільний застосунок для петицій надходить стільки запитів, скільки він бачив за добу.

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

Так і виглядає втрата підписів під час пікового навантаження. Зовнішній сервіс може відповідати повільно, віддавати відмову або порахувати один запит двічі — і тоді збір підписів онлайн або зупиняється, або наповнюється дублями.

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

Далі зависає модерація петицій. Поки перевірка ручна, потік у піку накопичується в черзі, автори чекають відповіді добами, частина звернень іде у відмову за формальними ознаками.

Великі майданчики на кшталт Change.org живуть із цим роками, але й там спірні випадки розбирають люди — автоматика закриває лише однотипні.

Нарешті, підтримка мобільного застосунку за залишковим принципом: про відмову дізнаються з відгуків, а не з метрик, повтор запису ніхто не перевірив, журнали не сходяться.

Кожен із цих збоїв закривається інженерно — повторюваним записом підпису, чергою з повторами, єдиним профілем, поетапною перевіркою. Розбираємо, як це влаштовано.

Що змінюється після впровадження: чотири вимірювані ефекти

Частка підтверджених підписів

Підпис фіксується лише після двох кроків: сам акт в інтерфейсі та підтвердження власника — за кодом у повідомленні або з прив'язки до облікового запису.

Дедуплікація відбувається за стійким ідентифікатором пристрою та контактом, тому повторне натискання не створює другий запис у реєстрі.

Замість ручного чищення «сирих» голосів у базі відразу лежать валідні — частка підтверджених підписів перестає бути предметом суперечки з перевіряючими.

Час реакції на пік

Кампанія в соцмережах приводить тисячі людей за хвилини, і саме тут звичайні збірки ламаються. Сервіси підписів масштабуються за навантаженням горизонтально, а запис іде через чергу: пік не валить форму, а розбирається в міру обробки, без втрати натискань. Інженерний сенс — форма відповідає за частки секунди навіть на порядок вище за звичний трафік.

Час відновлення після збою

Схема з реплікою та регулярними резервними копіями дозволяє повернути сервіс за хвилини, а не за години простою.

Регламент відкату до попередньої збірки відпрацьовано заздалегідь: якщо реліз поводиться не так, версія відкочується повністю, дані підтверджених підписів залишаються цілими.

Сповіщення про статус петиції надходять через Firebase — доставка не залежить від того, на якому вузлі в цей момент працює сервіс.

Зниклий клас відмов

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

Дублі на сервері відсікаються ключем, тому «підписав, а в реєстрі немає» та «підписав двічі» зникають як клас.

Усі чотири ефекти перевіряються на приймальних випробуваннях до запуску: ми подаємо пікове навантаження, обриваємо з'єднання й відкочуємо реліз.

Формати реалізації: нативний код, єдина база, веб-обгортка

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

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

Сценарій важливіший за платформу: якщо підпис ставиться в полі без стійкого зв'язку й потребує перевірки документа, єдина база з нативними вставками закриває задачу; якщо кампанія живе в стрічках соцмереж, вебзастосунок дає охоплення без встановлення.

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

Як відбувається впровадження: шість етапів від схеми до приймання

Збір підписів влаштований складніше, ніж форма з кнопкою: один підпис — це одна підтверджена дія однієї людини, і підтверджуваність важливіша за гарні екрани.

Тому ми ведемо впровадження фіксованою послідовністю — від аудиту того, як підписи збираються зараз, до передачі проєкту з доступами й документацією. Нижче порядок робіт, за яким видно, на якому кроці який ризик закривається.

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

Після передачі у вас залишається робоча система та зрозуміла документація, а не закрита скринька: супровід, доопрацювання й оновлення обговорюємо окремо, коли склад робіт зрозумілий. Опишіть задачу — повернемося з оцінкою та планом за цими етапами.

Що передаємо на руки: схеми, доступи, регламенти модерації

Передаємо не архів файлів, а робочий комплект: за кожним артефактом зрозуміло, хто власник, як його оновлювати й що робити при збої.

Акаунти магазинів застосунків, серверні ключі та панель розсилок оформлюємо на ваші реквізити з двофакторним захистом — доступ не залишається прив'язаним до підрядника.

• Схема даних підписів. Структура запису про підпис, зв'язок із кампанією та обліковим записом, унікальний ключ проти повторного підпису, журнал змін. Результат збору перевіряється за вивантаженням, а не за лічильником в інтерфейсі.
• Матриця ролей доступу. «Роль → дія»: гість, підписувач, модератор, адміністратор кампанії, власник. Окремо прописано, хто бачить персональні дані, а хто лише лічильники та статистику.
• Регламент модерації. Що публікується і що відхиляється, строки розгляду, порядок апеляції для автора петиції, ескалація спірних випадків.
• Інструкція для модераторів. Розбір черги покроково, критерії відхилення, шаблони відповідей авторам, дії при скаргах і масових однотипних підписах.
• Документація на застосунок. Збірка та випуск, конфігурація середовищ, схема інтеграцій, порядок правки правил модерації без випуску нової версії.
• План випуску оновлень. Порядок перевірки перед публікацією, умови відкату до попередньої версії, відповідальний за чергування після релізу.

Кейс: пікове навантаження і що ми змінили в схемі

Що було до змін

Публікація кампанії давала сплеск у 15–20 разів від звичайного потоку. Застосунок тримав рівний трафік, але на піку запис підпису ставав у чергу: частина сесій закінчувалася помилкою, людина натискала кнопку повторно й створювала дубль, який потім зводили вручну.

За логами до змін близько 8% сесій у момент публікації втрачали підтвердження, подача підпису займала в середньому 4 секунди, а розбір відхилення — 3–4 години ручної роботи чергового.

Що змінили в схемі і що стало

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

Масштабування перевели на Kubernetes: кількість реплік зростає від довжини черги, а не від завантаження процесора, — реакція починається раніше, ніж відвідувач відчує затримку. Реєстр підписів винесли на репліки читання, довідник активних кампаній прогріваємо до публікації.

Частка втрачених підтверджень на піку — 0,2% замість 8%, подача підпису — 0,6 секунди замість 4. Реакція на відхилення за автоматичним сповіщенням скоротилася з трьох годин до 12 хвилин, при цьому обсяг реєстру зріс утричі.

Схема тримає наступний пік без ручного втручання інженерів — той самий запас працює на кампаніях, які виходять одна за одною.

Чим платформа для збору підписів відрізняється від форми на сайті?

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

Мобільний застосунок бере на себе те, що браузер не тягне: офлайн-збір, підтвердження особи та нагадування.

Різниця проявляється на підтвердженні особи. У зборі підписів на сайті опора — код із повідомлення або лист, і одна людина з двома адресами залишить два записи.

У застосунку перевірка проходить один раз і закріплюється за пристроєм, а кожен новий підпис звіряється з уже збереженим ідентифікатором — повторна відсікається до запису.

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

Сповіщення влаштовані інакше: застосунок нагадує підтвердити підпис або донести відсутні дані, форма на сайті на це не здатна. Тому порівняння підходів зводиться не до «що краще», а до того, чи потрібен вам разовий сплеск підписів чи постійний збір із підтвердженням.

Часті запитання щодо модерації та петицій: розбираємо сумніви

Модерація петицій і захист від накрутки підписів — дві теми, через які запуск найчастіше відкладають. Нижче п'ять сумнівів, які спливають на етапі оцінки, і те, як кожен із них закривається інженерно.

Що станеться з уже зібраними підписами під час міграції?

База переноситься порціями, кожна пачка звіряється за контрольною сумою, дублі згортаються за ключем «кампанія + підписувач». Перемикання йде на читання з нової бази, стара залишається в репліці до кінця звірки. Відкат — одна команда, і він доступний у будь-який момент, поки розходження не дорівнює нулю.

Чи витримає застосунок пік під час гучної кампанії?

Підписи пишуться асинхронно через чергу, екран підтвердження віддається відразу й не чекає відповіді бази. Лічильники й списки кешуються, тому сплеск на одному екрані не валить інші розділи.

Лічильник перезбирається із затримкою в кілька секунд — це усвідомлений розмін точності на стійкість.

Що входить у підтримку застосунку після запуску?

Чергування за відмовами, оновлення під нові версії платформ, розбір збоїв у надсиланні коду підтвердження. Окремо ведемо модерацію: скарги на петиції та налаштування правил, коли з'являється новий сценарій накрутки. Порогові значення фільтрів змінюються без випуску нової збірки.

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

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

Обговоримо задачу: що надіслати для точної оцінки

Щоб оцінка розробки застосунку спиралася на факти, а не на здогади, достатньо кількох вхідних матеріалів.

Чим конкретніші ввідні, тим менше припущень у розрахунку строків і тим реалістичніший план впровадження за етапами — від перевірки підпису до вивантаження підписів на адресу отримувача. Надсилайте те, що вже є, решту уточнимо питаннями на дзвінку.

• Сценарії підписувача й автора петиції: створення, модерація, збір підписів, передача отримувачу.
• Правила перевірки підпису: як підтверджується унікальність людини і які дані залишаються в системі.
• Ролі та права: модератор, представник відомства, підтримка, доступ до статистики й вивантажень.
• Інтеграції: зовнішні реєстри, карти, сповіщення, аналітика, офіційні відповіді та звітність.
• Якщо рішення вже працює — аудит поточного рішення: вузькі місця, відмовостійкість, навантаження на підтримку.
• Референси та дизайн: брендбук, приклади інтерфейсів, вимоги до доступності для людей зі слабким зором.
• Вимоги до зберігання персональних даних, регіон розміщення серверів і строк зберігання історії.
• Пріоритети за етапами: що має потрапити в перший реліз, а що можна відкласти без втрати сенсу.

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