Розробка мобільного додатку для ставок на спорт

Чому webSocket кращий за REST для live-котирувань?

Букмекерські додатки обробляють тисячі оновлень котирувань за секунду. Затримка в 3–5 секунд перетворюється на фінансові втрати: клієнти ставлять за застарілими даними, а арбітражники виводять гроші. WebSocket забезпечує оновлення коефіцієнтів у 50 разів швидше, ніж long polling (100 мс проти 5 с), та знижує навантаження на сервер у 10 разів. В одному з проєктів з 5000+ одночасних підключень ми досягли затримки оновлення коефіцієнтів менше 100 мс. Це дозволило оператору скоротити втрати від арбітражних ставок на 30% та заощадити до $100,000 щомісяця.

Як працює WebSocket?

WebSocket — це постійне з'єднання, де клієнт підписується на події (SUBSCRIBE {market_ids: [123, 456]}), а сервер надсилає диф ({market_id: 123, outcomes: [{id: 1, odds: 2.45}]}). Клієнт застосовує зміни до локального state без перезавантаження.

• iOS: URLSessionWebSocketTask + Combine publisher дистриб'ютить оновлення по ViewModel'ам.
• Android: OkHttp WebSocket + StateFlow / SharedFlow через BettingRepository.
• При розриві — автоматичний reconnect з експоненціальним backoff та повторною підпискою.
• Візуально — мікроанімація при зміні коефіцієнта (зелений/червоний flash через animate() в Compose або UIView.animate в UIKit).

Suspended markets. Перед великою подією матч іде в suspend — ставки блокуються. Додаток отримує {market_id: 123, status: "suspended"} і негайно деактивує кнопку «Поставити». Якщо купон вже відкритий — показуємо inline попередження.

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

Використання idempotency_key у розміщенні ставок

idempotency_key (UUID клієнта) обов'язковий — запобігає дублюванню ставок при мережевих збоях. Він передається в POST /bets. Сервер перевіряє унікальність ключа за певний проміжок часу, що виключає повторне списання коштів.

Купон ставки (betslip) — архітектура та підводні камені

Betslip — технічно складний UI-компонент. Користувач додає наслідки, додаток рахує accumulator odds: total_odds = outcome_1_odds × outcome_2_odds × ... × outcome_n_odds. При зміні будь-якого коефіцієнта під час відкритого betslip — оновлення з анімацією та пропозицією прийняти нові умови.

Flow розміщення ставки:

1. Натискання «Поставити» → локальна валідація (баланс, мін/макс ставка).
2. POST /bets з {selections, stake, idempotency_key} → сервер резервує суму.
3. Відповідь: {bet_id, status: "accepted"/"pending"/"rejected", actual_odds}.
4. Якщо actual_odds змінилися — діалог «Коефіцієнт змінився. Прийняти?».

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

Геолокаційний контроль

Ліцензійні вимоги забороняють ставки за межами дозволеної території. Запитуємо CLLocationManager (iOS) або FusedLocationProviderClient (Android) при старті. Координати йдуть на сервер, сервер звіряє з GeoIP + device location. VPN detection: порівнюємо IP-геолокацію з GPS — суттєва розбіжність лише флаг для перевірки, а не бан.

Платежі та вивід: безпека передусім

Поповнення та вивід через Stripe, Adyen, PayOp або локальні PSP. Карткові дані не проходять через наш сервер — використовуємо Stripe SDK (iOS: Stripe iOS SDK, Android: Stripe Android SDK). Для виводу — обов'язкова верифікація (KYC) через Sumsub. Apple Pay / Google Pay для швидкого депозиту: інтеграція займає 1–2 дні при готовому бекенді.

Порівняння підходів та SDK

WebSocket краще підходить для live-котирувань: знижує навантаження в 10 разів порівняно з polling і забезпечує актуальність даних. При навантажувальному тестуванні ми емулювали 2000+ одночасних підключень і досягли 99.99% успішних оновлень.

Стек та архітектура

• iOS: Swift 5.9+, SwiftUI, Combine, async/await
• Android: Kotlin, Jetpack Compose, Hilt DI, Room, Coroutines + Flow
• Cross-platform: Flutter 3.x (Dart) або React Native (TypeScript) — але для live-котирувань краща нативна розробка
• Backend: GraphQL (Apollo) + REST + Codable, Firebase / Supabase
• Сховище: локальна БД (Room / Core Data) з міграціями для історії ставок

Архітектура: Clean Architecture — BettingRepository (WebSocket + REST), BetSlipViewModel (accumulator, validation), PaymentRepository, GeoLocationService.

Процес роботи: від аудиту до публікації

1. Аудит ліцензійних вимог та вибір юрисдикції
2. Проєктування API та WebSocket-контракту
3. Розробка real-time котирувань та betslip
4. Інтеграція платежів + KYC
5. Геолокаційний контроль
6. Навантажувальне тестування (1000+ одночасних оновлень)
7. Публікація в магазинах (App Store: gambling entitlement + ліцензія; Google Play: Gambling policy)

Що входить у результат

• Вихідний код додатку для iOS та/або Android
• WebSocket-контракт та документація API
• Налаштовані CI/CD (TestFlight, Firebase App Distribution)
• Інструкція з публікації та супроводу
• Гарантія на код протягом 30 днів після здачі

Наш досвід: 8+ років, 20+ проєктів, 5 років на ринку букмекерських рішень

Ми займаємося мобільною розробкою 8+ років. У портфоліо понад 20 проєктів, включаючи high-load букмекерські платформи. Ми працюємо на ринку мобільних букмекерських рішень понад 5 років, маємо сертифікати Apple Developer та Google Play Console. Середній час виведення MVP — 10 тижнів. Вартість розробки варіюється залежно від функціоналу та вимог до real-time, починається від $40,000.

• MVP (live та prematch котирування, одиночні та експрес-ставки, базові платежі): 8–12 тижнів.
• Повноцінна платформа (live streaming, cash out, мультивалютність, обидві платформи): 3–5 місяців.

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