Розробка мобільного додатка для продажу билетів на мероприятия
Головна технічна біль ticketing-додатка — конкурентна продаж. Коли 500 людей одночасно натискають "Купити" на останніх 10 місцях, додаток обов'язково повинен коректно обробити це без двійних продажей, зависань та некоректних статусів. Це не frontend-завдання — це проектування серверної частини з песимістичними блокуваннями або резервуванням через чергу. Але мобільний клієнт також має бути готовий до сценарію "місце вже займано".
Резервування місць та race condition
Стандартна схема: користувач вибирає місце → сервер створює reservation з TTL 10 хвилин → користувач платить → reservation конвертується у ticket. Якщо оплата не пройшла за 10 хвилин — місце звільняється.
На мобільному клієнті таймер резервування — це CountDownTimer (Android) або Timer.scheduledTimer (iOS), синхронізований з серверним TTL. Не з моменту натиску кнопки на клієнті, а з reservation.expiresAt з відповіді сервера. Різниця часових поясів та дрейф системних годин пристрою убивають UI-таймер, якщо синхронізувати неправильно.
// Android: синхронізація таймера з серверним expiresAt
class ReservationViewModel : ViewModel() {
private val _timeLeft = MutableStateFlow(0L)
val timeLeft: StateFlow<Long> = _timeLeft
fun startCountdown(expiresAt: Instant) {
viewModelScope.launch {
while (true) {
val remaining = ChronoUnit.SECONDS.between(Instant.now(), expiresAt)
if (remaining <= 0) {
_timeLeft.emit(0)
onReservationExpired()
break
}
_timeLeft.emit(remaining)
delay(1000)
}
}
}
}
При закінченні резервування — не просто показуємо помилку. Автоматично пропонуємо найближчі доступні місця, якщо потік реального часу (WebSocket або SSE) це підтримує.
Схема місць та інтерактивний зал
Для концертних залів та театрів потрібна інтерактивна схема. На iOS — UICollectionView з кастомним UICollectionViewLayout або Canvas у SwiftUI для залів з нестандартною геометрією. На Android — Canvas + GestureDetector для pinch-to-zoom.
Схема завантажується як JSON з координатами кожного сиденяня, секцією та статусом (available, reserved, sold, disabled). Оновлення статусів у реальному часі — через WebSocket: як тільки хтось зарезервував місце, всім підключеним клієнтам летить { type: "seat_reserved", seatId: "A-15" }.
SVG-схеми залів — популярний варіант для кросс-платформенних рішень. React Native з react-native-svg або Flutter з flutter_svg + GestureDetector рендерять SVG з можливістю tap по елементам.
Електронні билеты та валідація на вході
Кожен куплений билет отримує унікальний UUID та QR-код, сгенерований на сервері. Хранити секрет у QR не потрібно — достатньо ticketId, верифікація відбувається на сервері при сканованні. QR не повинен бути статичним зображенням у PDF — генеруємо його динамічно з ticketId на клієнті через ZXingObjC (iOS) або zxing-android-embedded, щоб не зберігати растрове зображення у базі.
Додаток контролера — окремий екран або окремий додаток зі сканером AVFoundation/CameraX, POST /tickets/{id}/validate, відповідь: valid / already_used / invalid. Кешуємо валідовані ticketId локально на пристрої контролера на випадок відсутності інтернету — синхронізація після відновлення зв'язку.
Платіжний флоу
Еквайринг — ЮKassa, CloudPayments або Stripe. На iOS додатково Apple Pay (PKPaymentRequest), на Android — Google Pay. Для b2b сегмента — виставлення рахунку по email з оплатою через СБП.
Після оплати негайна відправка PDF-биліту на email через SendGrid/Postmark та push-сповіщення через FCM/APNs з deep link на екран "Мої билеты".
Типові помилки
Double booking. Без SELECT FOR UPDATE або distributed lock на рівні reservationId + seatId два користувачі можуть створити резервування на одне місце. На PostgreSQL — advisory locks або ON CONFLICT DO NOTHING при вставці резервування.
QR на скриншоті. Не ставте захист від скриншотів — це ломає UX. Замість цього QR повинен бути одноразовим при валідації: перший скан — ОК, другий — already_used.
Етапи та сроки
Проектування моделі даних (залів, секцій, місць, событій) → схема місць → резервування з TTL → оплата → електронні билеты → додаток контролера → тестування навантаження.
6–10 тижнів для повнофункціонального додатка з інтерактивною схемою зала, real-time обновленнями та додатком контролера. Вартість розраховується індивідуально після аналізу вимог.