Ми розробляємо аукціонні додатки, де кожна мілісекунда затримки — втрачений лот. Уявіть: на торгах за рідкісний предмет залишається 30 секунд, і раптом сервер не відповідає 2 секунди — користувач втрачає шанс зробити ставку. Такі сценарії ми закриваємо архітектурою на WebSocket та оптимістичним блокуванням. Нижче розберемо ключові технічні рішення: WebSocket з автоперепідключенням, обробку гонки умов, автоставки (proxy bidding) та anti-sniping.
Аукціонний додаток — це не просто каталог товарів. Його серце — реальний час, де узгодженість даних критична. Без правильної системи версій та бізнес-логіки користувачі бачитимуть застарілі ціни та втрачатимуть ставки. Розглянемо перевірену архітектуру, що витримує тисячі одночасних з'єднань.
Як розробити мобільний додаток для аукціону з нуля?
Проектування починається з вибору транспорту та протоколу синхронізації. Ми використовуємо WebSocket (протокол описаний у RFC 6455) та оптимістичне блокування на рівні бази даних. Визначаємо події: BID_PLACED, AUCTION_EXTENDED, AUCTION_ENDED, YOU_WON, YOU_WERE_OUTBID. Кожна подія містить версію лота для перевірки узгодженості.
Чому WebSocket, а не polling?
Polling для аукціону — неприйнятно: затримка в 5-10 секунд при опитуванні HTTP призводить до втрачених ставок. WebSocket з перепідключенням — стандарт, що забезпечує затримку <100 мс. Це в 50-100 разів швидше, ніж polling, що критично для аукціонів з високою активністю.
| Метод | Затримка | Надійність |
|---|---|---|
| Polling (HTTP) | 5-10 секунд | Середня — часті запити навантажують сервер |
| WebSocket | <100 мс | Висока — автоматичне відновлення з'єднання |
Реалізація на Swift та Kotlin:
Swift WebSocket (URLSessionWebSocketTask)
// iOS: WebSocket через URLSessionWebSocketTask
class AuctionWebSocket {
private var webSocketTask: URLSessionWebSocketTask?
private var reconnectTimer: Timer?
func connect(auctionId: String) {
let url = URL(string: "wss://api.yourauction.com/auctions/\(auctionId)/live")!
webSocketTask = URLSession.shared.webSocketTask(with: url)
webSocketTask?.resume()
receive()
}
private func receive() {
webSocketTask?.receive { [weak self] result in
switch result {
case .success(let message):
if case .string(let text) = message {
self?.handleMessage(text)
}
self?.receive() // продовжуємо слухати
case .failure:
self?.scheduleReconnect()
}
}
}
private func scheduleReconnect() {
reconnectTimer?.invalidate()
reconnectTimer = Timer.scheduledTimer(withTimeInterval: 3.0, repeats: false) { [weak self] _ in
self?.connect(auctionId: self?.currentAuctionId ?? "")
}
}
}
Kotlin WebSocket (OkHttp)
// Android: OkHttp WebSocket
class AuctionWebSocketManager(
private val client: OkHttpClient,
private val scope: CoroutineScope
) {
private val _events = MutableSharedFlow<AuctionEvent>()
val events: SharedFlow<AuctionEvent> = _events.asSharedFlow()
fun connect(auctionId: String) {
val request = Request.Builder()
.url("wss://api.yourauction.com/auctions/$auctionId/live")
.build()
client.newWebSocket(request, object : WebSocketListener() {
override fun onMessage(webSocket: WebSocket, text: String) {
scope.launch {
val event = json.decodeFromString<AuctionEvent>(text)
_events.emit(event)
}
}
override fun onFailure(webSocket: WebSocket, t: Throwable, response: Response?) {
scope.launch {
delay(3000)
connect(auctionId)
}
}
})
}
}
Як уникнути гонки умов при одночасних ставках?
Найскладніша бізнес-логіка: два користувачі роблять ставку одночасно. Приклад:
- Поточна ставка: 1000 ₴
- Користувач A бачить 1000 ₴, робить ставку 1100 ₴
- Користувач B бачить 1000 ₴, робить ставку 1050 ₴
- Обидві ставки приходять на сервер в один момент
Правильне рішення — оптимістичне блокування з версією лота. Воно краще за песимістичне блокування, оскільки не блокує рядок на читання та забезпечує високу пропускну здатність. Сервер перевіряє версію лота перед оновленням:
def place_bid(user_id: str, lot_id: str, amount: Decimal, expected_version: int) -> BidResult:
with db.transaction():
lot = db.select_for_update(f"SELECT * FROM lots WHERE id = %s", lot_id)
if lot.version != expected_version:
return BidResult(
success=False,
reason="LOT_UPDATED",
current_bid=lot.current_bid,
new_version=lot.version
)
if amount <= lot.current_bid:
return BidResult(
success=False,
reason="BID_TOO_LOW",
current_bid=lot.current_bid,
new_version=lot.version
)
db.execute(
"UPDATE lots SET current_bid=%s, current_bidder=%s, version=version+1 WHERE id=%s",
(amount, user_id, lot_id)
)
db.execute(
"INSERT INTO bids (lot_id, user_id, amount) VALUES (%s, %s, %s)",
(lot_id, user_id, amount)
)
broadcast_to_websockets(lot_id, {
"type": "BID_PLACED",
"amount": str(amount),
"bidder": mask_username(user_id),
"version": lot.version + 1
})
return BidResult(success=True, new_version=lot.version + 1)
При LOT_UPDATED клієнт отримує актуальну ставку та може запропонувати користувачеві зробити нову з урахуванням поточної ціни. Так ми уникаємо подвійних списань та некоректного балансу.
Як працює автоставка?
Користувач встановлює максимальну суму, яку готовий заплатити. Система автоматично підвищує його ставку у відповідь на ставки конкурентів — до встановленого максимуму.
def process_autobid(lot_id: str, new_bid_amount: Decimal, new_bidder_id: str):
"""Перевіряємо автоставки після кожної нової ставки"""
autobids = db.get_active_autobids(lot_id, exclude_user=new_bidder_id)
for autobid in sorted(autobids, key=lambda x: x.max_amount, reverse=True):
counter_amount = new_bid_amount + lot.bid_step
if counter_amount <= autobid.max_amount:
# Автоматично ставимо від імені власника автоставки
place_bid(autobid.user_id, lot_id, counter_amount, lot.version)
break
Автоставка — джерело конфліктів з користувачами, тому важлива детальна історія: «Ваша ставка 1 200 ₴ була автоматично підвищена у відповідь на ставку 1 100 ₴». Користувач завжди бачить, що сталося, і може скоригувати ліміт.
Що таке anti-sniping?
Снайпінг — ставка в останні секунди. Щоб його уникнути, аукціон продовжується при ставці в кінці:
ANTI_SNIPING_THRESHOLD = timedelta(minutes=2)
ANTI_SNIPING_EXTENSION = timedelta(minutes=2)
def after_bid_placed(lot_id: str):
lot = db.get_lot(lot_id)
time_remaining = lot.ends_at - datetime.utcnow()
if time_remaining < ANTI_SNIPING_THRESHOLD:
new_end_time = lot.ends_at + ANTI_SNIPING_EXTENSION
db.update_lot_end_time(lot_id, new_end_time)
broadcast_to_websockets(lot_id, {
"type": "AUCTION_EXTENDED",
"new_end_time": new_end_time.isoformat()
})
Таймер на клієнті синхронізується з серверним часом при отриманні AUCTION_EXTENDED. Це дає всім учасникам рівні шанси на відповідну ставку.
Як організувати платежі?
Переможець отримує push-сповіщення та має обмежений час (24–48 годин) для оплати. Якщо не оплатив — лот переходить наступному за ставкою або виставляється повторно.
Для цінних лотів — передоплата перед участю: депозит блокується при реєстрації на торги, повертається тим, хто програв.
Комісія з продажу (покупця або продавця) утримується при оплаті. Payouts продавцю — через Stripe Connect або аналог. Якщо вам потрібна нестандартна схема розрахунків, зв'яжіться з нами — підберемо рішення.
Орієнтири за термінами
| Scope | Термін |
|---|---|
| Перегляд лотів, WebSocket, ставки, push-сповіщення | 6–8 тижнів |
| Автоставки, anti-sniping, історія ставок | +2 тижні |
| Кабінет продавця, публікація лотів, payouts | +3–4 тижні |
| Депозити та escrow | +1–2 тижні |
Вартість розраховується індивідуально після аналізу вимог.
Що входить в роботу?
- Технічне завдання та прототип UI/UX
- Розробка під iOS (Swift, SwiftUI) та Android (Kotlin, Jetpack Compose)
- Backend на Python/FastAPI або Node.js
- Інтеграція WebSocket з перепідключенням
- Реалізація автоставок та anti-sniping
- Платіжна система (депозити, escrow, payouts)
- Тестування (unit, UI, load)
- Публікація в App Store та Google Play
- Документація та навчання адміністраторів
- Гарантійна підтримка 3 місяці
Отримайте консультацію по вашому проекту. Ми оцінимо терміни та запропонуємо оптимальне рішення. Наш досвід гарантує стабільну роботу аукціону навіть при високому навантаженні. Зв'яжіться з нами, щоб обговорити архітектуру та деталі реалізації.