ЛЕНТЫ КОЭФФИЦИЕНТОВ
Принимать несколько потоков поставщиков с временными метками, проверкой последовательности и понятным приоритетом источников.
БУКМЕКЕРСКИЕ СЕРВИСЫ / EVENT-DRIVEN СИСТЕМЫНа главную ↗
КАЖДОЕ ОБНОВЛЕНИЕ ДОЛЖНО БЫТЬ БЫСТРЫМ, УПОРЯДОЧЕННЫМ И ПРОВЕРЯЕМЫМ
Букмекерские системы работают рядом с live-событиями, ценовыми фидами и пользовательскими транзакциями. Платформа должна двигаться быстро, сохраняя порядок, трассируемость и контролируемое поведение при отказах.
EVENT BUS
Использовать долговечные потоки и идемпотентных потребителей, чтобы replay и retry не создавали противоречивое состояние.
RISK PATH
Держать проверки экспозиции и транзакций рядом с write-path, не превращая каждое обновление в глобальную блокировку.
АУДИТ
Сохранять неизменяемую историю событий для разборов инцидентов, сверки и compliance-процессов.
Низкая задержка полезна только тогда, когда состоянию можно доверять.
Более быстрый фид не помогает, если запоздавший пакет перезаписывает свежую цену. Номера последовательности, event time и идемпотентность превращают скорость в корректность при повторах и частичных отказах.
Read-heavy просмотр рынков лучше отделять от транзакционных записей. Пользователь может обновлять страницу постоянно, но размещение ставки, изменение баланса и риск-проверки требуют более строгой согласованности и явной границы аудита.
Три детали, которые меняют устойчивость системы.
Позднее событие не равно новому
Каждому потребителю нужно правило, которое отличает недавно полученное событие от действительно более нового состояния.
Два поставщика могут иметь один общий отказ
Резервирование работает только тогда, когда вторичные фиды, сетевые пути и доступы проверяются независимо.
Журнал событий — часть эксплуатации
Долговечная история уменьшает количество догадок при сверке состояния после повторов, пропусков фида или регионального переключения.
Транзакционный write-path должен быть коротким и хорошо наблюдаемым.
Страницы рынков допускают агрессивное кэширование и eventual refresh. Транзакционные записи — нет. Разделение потоков позволяет чтению масштабироваться широко, а критическому write-path сохранять явную валидацию, риск-проверки, надёжное хранение и trace-id.
Пять вопросов перед масштабированием букмекерского сервиса
- 01
Может ли старое обновление фида перезаписать новую цену?
- 02
Идемпотентны ли повторные попытки во всех транзакционных потребителях?
- 03
Может ли слой чтения масштабироваться независимо от write-path?
- 04
Failover фидов реально тестируется или только настроен?
- 05
Можно ли восстановить каждое критическое изменение состояния из долговечных событий?