Мы разрабатываем аукционные приложения, где каждая миллисекунда задержки — потерянный лот. Представьте: на торгах за редкий предмет остаётся 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 месяца
Получите консультацию по вашему проекту. Мы оценим сроки и предложим оптимальное решение. Наш опыт гарантирует стабильную работу аукциона даже при высокой нагрузке. Свяжитесь с нами, чтобы обсудить архитектуру и детали реализации.