Чому застосунок таксі ламається на піку замовлень
Пік замовлень розкриває те, що не видно на тестовому стенді: застосунок таксі перестає бути набором екранів і перетворюється на систему реального часу, де розсинхрон на секунду коштує втраченого водія.
Першим здається матчинг — під час шторму замовлень два диспетчерські вузли одночасно призначають одного водія на дві поїздки, і обидва пасажири бачать «машина їде», поки водій бачить одну адресу.
Далі каскад: замовлення йде в чергу, але подія про призначення губиться, і поїздка зависає в статусі «пошук» — пасажир скасовує, водій простоює, а сервіс платить за обидва простої репутацією.
Точність геолокації в застосунку таксі ламається інакше. На щільній забудові телефон віддає координати з дрейфом, а за слабкого сигналу — із затримкою в десятки секунд.
Якщо точка водія оновлюється рідше, ніж змінюється його положення, карта малює машину там, де її вже немає, а розрахунок часу подачі бреше. Пасажир виходить на вулицю і не знаходить автомобіль — формально система спрацювала, фактично поїздка зірвана.
Проблема не в самій карті, а в тому, як застосунок фільтрує та згладжує потік координат перед відправленням на сервер.
Окремий клас — відвал платежів. Прив'язана карта списується в момент завершення поїздки, і якщо еквайринг відповідає повільно або повертає неоднозначний статус, гроші не списуються, а поїздка закривається.
Повторний запит без ідемпотентності призводить до подвійного списання — і це вже не технічний збій, а повернення, звернення та втрата довіри.
Збої матчингу водіїв, завислі замовлення таксі та платежі — це один пов'язаний ланцюжок, де слабка ланка визначає надійність усього сервісу.
Ціна кожного вузького місця рахується не в рядках коду, а в зірваних поїздках: частка замовлень, що дійшли до завершення, час від заявки до призначення водія, частка скасувань із вини системи.
Розбираємо, як це закривається на рівні архітектури — від черг і блокувань до обробки координат та ідемпотентних платежів.
Архітектура сервісу таксі: матчинг, гео, платежі
Розробка застосунку для таксі тримається на трьох підсистемах, кожна з яких вимірюється своїми метриками. Матчинг визначає, за скільки секунд замовлення знаходить водія і яку частку поїздок вдається закрити без скасувань.
Геолокація в застосунку таксі задає точність позиції та плавність треку на карті. Інтеграція платежів у таксі — частку успішних списань і швидкість повернень при скасуванні. Нижче — як ці частини влаштовані та що дає кожна.
Матчинг: жадібний проти батчевого
Жадібний алгоритм матчингу водіїв віддає замовлення найближчому вільному водієві одразу — просто, але на пікових зонах дає перекіс: частина машин їде через весь район, час подачі зростає.
Батчевий матчинг збирає заявки вікнами по кілька секунд і розв'язує задачу розподілу цілком — час подачі падає, частка успішних замовлень зростає, але з'являється затримка на саме вікно. На практиці ставлять гібрид: жадібний у центрі, батчевий у щільних зонах.
Геолокація: частота і точність
Позиція водія надходить потоком; якщо писати кожну точку в базу, вона захлинається на сотнях машин. Точки буферизуються в пам'яті та скидаються пакетами, а карта отримує згладжений трек — без ривків і «телепортів» між вимірами. Це знижує навантаження на сховище та прибирає хибні спрацювання геозон.
Платежі: ідемпотентність і повернення
Списання прив'язане до поїздки унікальним ключем, тому повторний запит не створює друге списання. Скасування ініціює повернення тим самим ключем — гроші не «зависають», а спірні операції розбираються за логом.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Жадібний матчинг | Низька щільність замовлень, мале місто | Перекіс на піках, зростає час подачі |
| Батчевий матчинг | Щільні зони, висока конкуренція за замовлення | Затримка на вікно, складніше налагодження |
| Гібрид | Міста зі змішаним навантаженням | Потрібне налаштування порогів за зонами |
| Зовнішній платіжний шлюз | Швидкий старт, готові методи оплати | Залежність від чужого SLA |
| Власний платіжний шар | Повний контроль над поверненнями та логами | Більше роботи на старті |
PostGIS для геозапитів і побудови зон — перевірений шар, який тримає просторові вибірки під навантаженням.
Кожна підсистема закриває свій клас відмов: матчинг — довгі подачі та скасування, гео — неточні треки та хибні геозони, платежі — подвійні списання та завислі повернення.
Як ми ведемо проєкт: від аудиту до передачі
Розробка застосунку для таксі рідко стартує з чистого аркуша: частіше є диспетчерська, водійський застосунок, база замовлень і набір інтеграцій, які вже працюють — і ламаються під навантаженням у годину пік.
Тому проєкт ведемо як інженерну послідовність, де кожен етап дає перевірюваний артефакт, а не статус у звіті. Нижче — як це влаштовано.
- Аудит поточного стану. Розбираємо наявні сервіси, схеми даних, логи матчингу та скарги підтримки. На виході — карта вузьких місць: де губляться замовлення, на якому кроці водій і пасажир бачать розсинхрон, які інтеграції тримають систему.
- Схема сервісів і межі відповідальності. Фіксуємо, що залишається, що переписуємо, що виносимо в окремий контур. Визначаємо контракти між матчингом, геолокацією, платежами та повідомленнями — щоб зміни в одному не валили решту.
- Матчинг і геолокація. Налаштовуємо радіуси пошуку, пріоритети водіїв, обробку «холодних» зон і черг замовлень. Окремо — поведінку при втраті сигналу: замовлення не повинно зависати в статусі «шукаємо машину».
- Платежі та статуси поїздки. Проводимо наскрізний шлях оплати: холдування, списання, повернення, скасування на різних етапах. Звіряємо, що стан замовлення в застосунку, на сервері та в платіжному контурі збігається.
- Тестування під навантаженням. Проганяємо сценарії пікових годин: сплеск замовлень, масовий вихід водіїв на лінію, обрив зв'язку в частини клієнтів. Дивимося час відгуку матчингу та частку замовлень, доведених до призначення водія.
- Передача проєкту замовнику. Віддаємо репозиторії, схеми сервісів, конфігурації середовищ, інструкції з розгортання та регламент релізів. Команда замовника може зібрати, викотити й відкотити версію без нас.
Кожен етап закінчується демонстрацією на реальних даних, а не презентацією. Якщо на аудиті видно, що дешевше полагодити наявний контур, ніж будувати новий, — говоримо про це прямо. Опишіть задачу: повернемося з оцінкою та планом за етапами.
Чим відрізняється власний матчинг від готового?
Готове рішення для таксі — це бібліотека матчингу всередині платформи: ви віддаєте їй координати водіїв і замовлень, а на виході отримуєте пару «водій–замовлення». Логіка закрита: найближчий вільний, черга, прості пріоритети.
Для міста з рівномірним попитом і парком у кілька десятків машин цього достатньо — запуск швидший, підтримувати нічого, поведінка передбачувана.
Власний матчинг замовлень починається там, де готова логіка перестає враховувати вашу економіку.
Розподіл замовлень таксі — це не «хто ближче», а задача з обмеженнями: утримати водія в зоні підвищеного попиту, не дати йому простоювати після далекої подачі, збалансувати завантаження між районами, врахувати рейтинг, клас авто та історію скасувань. Готове рішення такі ваги або не підтримує, або ховає за фіксованими налаштуваннями.
Різниця проявляється в метриках, а не в описі. Власний алгоритм дозволяє змінювати пріоритети без релізу застосунку — правило на боці сервісу, водій отримує оновлену логіку одразу.
Це дає керований відсоток подач у межах цільового часу, зниження холостого пробігу та передбачуване завантаження в години пік. Зворотний бік — матчинг стає вашою відповідальністю: тести, навантаження, відкат версій, моніторинг аномалій.
Порівняння підходів матчингу зводиться до трьох питань. Наскільки ваша економіка відрізняється від типової — якщо сильно, готова логіка буде тягнути вниз. Чи є у вас дані та люди, щоб крутити ваги — власний алгоритм без аналітика марний.
І як швидко потрібен запуск — готове рішення виводить продукт на ринок раніше, а власний матчинг окупається на обсязі, коли кожна частка відсотка подач конвертується у виручку парку.
Практичний шлях — гібрид: старт на готовій логіці, збір телеметрії щодо подач і скасувань, потім винесення матчингу в окремий сервіс, коли накопичиться статистика для ваг. Так ви не платите за складність раніше часу і не впираєтесь у стелю готового рішення, коли парк виросте.
Кейс: як зросла частка успішних замовлень
Сервіс працював на підрядній збірці: заявка йшла в ручний диспетчер, водій отримував адресу текстом і телефонував уточнювати під'їзд. На піку вечірніх годин це давало до 28% скасувань — пасажир ішов до конкурента, поки машина кружляла по двору.
Метрики сервісу таксі ми знімали з двох сторін: події в застосунку пасажира і в застосунку водія, плюс журнал диспетчерської — розбіжність між ними і показала, де губляться замовлення.
Що змінили в матчингу та геолокації
Переписали ядро розподілу: заявка більше не чекає вільного диспетчера, а йде напряму найближчим водіям з урахуванням їхнього поточного курсу та завантаженості вулиць.
Точку подачі визначаємо за геокодом будівлі, а не за центроїдом району — водій приїжджає до конкретного під'їзду, дзвінок «де ви стоїте» зникає зі сценарію. Це прибрало основну причину скасувань на етапі подачі.
Що змінили в оплаті
Платіжний сценарій перевели на токенізацію картки при першому замовленні: списання йде без повторного введення даних і без редіректу на сторонню сторінку.
Частка платежів, що падають на підтвердженні, скоротилася з 9% до 1,5% — водій бачить статус оплати до початку поїздки і не скасовує замовлення через ризик не отримати гроші.
| Метрика | До | Після |
|---|---|---|
| Середній час подачі | 11 хв | 6 хв |
| Частка скасувань замовлень | 28% | 9% |
| Точність геопозиції подачі | ±180 м | ±25 м |
| Успішні оплати з першої спроби | 91% | 98,5% |
Дані збирали два тижні до релізу і три тижні після, на зіставному обсязі замовлень і в однакові години — порівняння коректне, а не «до свят і після».
Окремо рахували частку успішних замовлень таксі від створених: зростання з 64% до 88%, тобто кожне четверте втрачене замовлення повернулося у виручку без залучення нових водіїв.
Матчинг побудований на відкритому стеку геопросторових запитів — PostGIS тримає індекс за координатами і віддає найближчих водіїв за частки секунди навіть на щільному потоці.
А якщо водії працюють на старих телефонах? Ядро матчингу живе на сервері, застосунок водія лише надсилає координати і отримує заявку — вимоги до пристрою не зросли, оновлення проходить без заміни парку.
Як відкочувалися, якщо метрики падали? Реліз ішов за перемикачем: стара логіка розподілу залишалася робочою, повернення займало хвилини і не вимагало викочувати нову збірку в магазини.
На руки замовник отримує схему потоку заявки, конфігурацію геоіндексів, політику ретраїв платежів, дашборд за метриками сервісу та інструкцію для підтримки. Опишіть своє завдання — повернемося з оцінкою та планом.
Сумніви перед стартом: доступи, міграція, відкат
Перед стартом розробки застосунку для таксі замовник зазвичай тримає в голові три питання: що доведеться віддати підряднику, як пройде міграція сервісу таксі з поточного рішення і що буде, якщо новий реліз зламає поїздки в годину пік.
Відповідаємо по суті: доступи до інфраструктури видаються за принципом мінімально необхідних — окремі облікові записи з обмеженою роллю, ключі до платіжного контуру та карток залишаються у вас, а наші інженери працюють через ваш контроль доступу з журналом дій.
Що якщо знадобиться відкат змін? Кожен реліз викочується поетапно: спочатку на частку водіїв і пасажирів, потім на весь потік. Поки нова версія не підтвердила стабільність, попередня збірка залишається готовою до повернення — перемикання займає хвилини, а не години простою.
Схема даних під час міграції розширюється сумісно: старі та нові поля живуть паралельно, тому відкат не потребує зворотного перетворення бази.
Що якщо у вас уже є працюючий сервіс? Переносимо частинами — спочатку матчинг і геолокацію, потім платежі та історію поїздок, звіряючи метрики на кожному кроці. Поки новий контур не показує зіставні результати, старий продовжує обслуговувати замовлення.
Кому належать вихідники та доступи після здачі?
Усе залишається у вас: репозиторії, інфраструктурні облікові записи, ключі, домени. Ми передаємо їх за актом і відкликаємо свої доступи — подальша підтримка йде вже за окремою угодою.
На руки замовник отримує:
- конфігурації середовищ (розробка, тест, продуктив) з описом змінних;
- схеми архітектури та потоків даних: геолокація, матчинг, платежі, повідомлення;
- політики доступу та рольову модель для команди й підрядників;
- регламент релізів і процедуру відкату змін з критеріями;
- документацію по проєкту: опис модулів, інтеграцій і точок відмови;
- інструкції з моніторингу ключових метрик — час подачі, частка скасувань, помилки платежів.
Опишіть задачу та поточний контур — повернемося з оцінкою, планом міграції та складом документації, що передається.
