Архітектура букмекерської платформи: ставки, гаманець і розрахунки

Букмекерська архітектура заслуговує на довіру, коли дає змогу пояснити ставку після незручного збою. Провайдер її прийняв, але відповідь загубилася. Кошти зарезервовано, але підтвердження гаманця запізнилося. Виграш зараховано, а потім результат виправлено. Жодну з цих ситуацій не можна надійно розв'язати, дивлячись лише на одне поле статусу.

Основне завдання проєктування — зберігати узгодженість трьох записів у часі: що прийняв оператор, що сталося з грошима клієнта і який результат застосовано. У цьому матеріалі розробляємо модель станів і розбираємо конкретну ставку для продуктової, інженерної та операційної команд. Передбачено ставки з фіксованими коефіцієнтами й гаманець облікового запису; біржам ставок, тоталізаторам і кредитним схемам потрібні інші грошові правила.

Розподіліть повноваження до розділення сервісів

Спочатку розділіть логічні обов'язки. Компонент пропозиції відповідає за поточну доступність ринків і результатів для ставки. Компонент приймання — за рішення щодо ставки та прийняті умови. Гаманець — за резерви й проведені грошові операції. Управління коефіцієнтами та ризиком — за ліміти приймання й модель зобов'язань. Компонент розрахунку — за застосування підтверджених результатів за відповідними правилами. Підтримка може переглядати спільну історію, але не має ставати альтернативним джерелом змін фінансового стану.

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

За зовнішнього постачальника управління коефіцієнтами або приймання чітко назвіть рішення, за яке він справді відповідає. Повідомлення про коефіцієнти не доводить, що постачальник прийняв ставку. Через адаптер зберігайте ідентифікатор його запиту, остаточний ідентифікатор ставки й підтвердження рішення. Продуктові межі визначаються в обсязі букмекерського продукту; інженерну роботу на межах постачальників розглядаємо в матеріалі про послуги інтеграції платформ.

Розділіть стани ставки, її коштів і результату

Використовуйте окремі групи станів, вибравши назви для своєї реалізації:

• Розміщення: запит отримано, очікує рішення, ставку прийнято або відхилено. Тайм-аут зв'язку означає невизначеність рішення, а не підтверджує відмову.
• Кошти: не зарезервовані, зарезервовані, списані на оплату ставки або звільнені з резерву. Резерв зменшує доступну для витрачання суму. Його списання обліковує ставку як оплачену й не має списувати її суму вдруге. Зняття ще не списаного резерву відрізняється від повернення оплаченої ставки: для повернення потрібна окрема грошова операція.
• Розрахунок: очікує підтверджувальних даних, готовий до застосування, застосований або очікує виправлення. Запис розрахунку посилається на дані, правила й грошову операцію, на підставі яких його виконано.

Визначте дозволені поєднання разом із переходами. Задайте строк вирішення роботи в очікуванні, але не перетворюйте його на автоматичну відмову або зняття резерву, якщо контракт авторитетної системи не підтверджує відсутності прийнятої ставки. Прийнята ставка із зарезервованими коштами може бути проміжним станом, з якого можна відновитися: рішення зовнішнього провайдера вже відоме, але списання резерву гаманцем ще не підтверджено. Прийнята ставка зі знятим резервом — виняток, що потребує розслідування, а не штатно завершений сценарій. Позначайте розрахунок застосованим лише після підтвердження його грошової операції; до цього показуйте передбачений результат і операцію в очікуванні. Запис має посилатися на оплачену суму ставки й конкретне застосування результату.

Зберігайте початкові параметри вибору, прийнятий коефіцієнт, суму, валюту й посилання на правила. Поточний ринок може закритися або зникнути без зміни цих умов. Використовуйте локальну версію ставки для захищених перевіркою оновлень та окремі ідентифікатори запитів, повідомлень провайдера й грошових операцій. Один спільний ідентифікатор не дає змоги відобразити кілька обґрунтованих виправлень однієї ставки.

Проведіть одну ставку через дозволені переходи

Розгляньмо умовну ставку B71: у клієнта спочатку 100 грошових одиниць, він робить ординар на 20 із десятковим коефіцієнтом 3,00. Припускаємо відсутність податків, комісій, бонусів і дострокового викупу. Ось робоча модель перевірки, виражена переходами, а не переліком функцій:

1. Отримання запиту: збережіть ідентифікатор запиту відправника й незмінні параметри розміщення. Обмежте перевірку повторів відповідним клієнтом та областю оператора. Зміна суми з тим самим ідентифікатором — конфлікт; навмисній другій ставці потрібен новий ідентифікатор.
2. Резервування: забезпечте 20 через механізми гаманця для одночасних операцій і зарезервуйте потрібну частину ліміту ризику. У моделі, де резерв не змінює обліковий баланс, баланс за проведеними операціями залишається 100, а доступні кошти стають 80. До надсилання збережіть команду постачальнику, яка очікує виконання.
3. Прийняття: збережіть остаточне підтвердження прийняття й точні прийняті умови. Списання наявного резерву робить обліковий баланс рівним 80: резерву більше немає, доступні кошти й далі становлять 80. В одній базі це можна виконати атомарно; між системами зберігайте відоме підтвердження прийняття й повторюйте ту саму операцію списання резерву, доки її статус не буде з'ясовано.
4. Відмова як альтернативна гілка: остаточна відмова до прийняття звільняє резерв коштів і зобов'язань за ризиком, що очікують рішення. Обліковий і доступний баланси повертаються до 100. Загубленої відповіді недостатньо для такого переходу.
5. Розрахунок: після прийняття застосуйте дозволений виграшний результат до оплаченої ставки. Загальна виплата становить 20 × 3,00 = 60, включно із сумою ставки, тому обліковий баланс стає 140. Застосовуйте цю грошову операцію один раз, навіть за повторної доставки результату.
6. Виправлення: якщо дані, підтверджені уповноваженим джерелом, змінюють перемогу на програш за застосовними правилами, сторнуйте зарахування 60 пов'язаною операцією. Обліковий баланс стає 80. Не списуйте ще 20: початкова ставка вже оплачена.

Відмова — альтернативна гілка, а не крок після прийняття. Числа показують модель резерву, а не універсальний API гаманця. Інший гаманець може представляти резерв інакше; доступна сума й підсумковий грошовий ефект однаково мають збігатися. Кожному переходу потрібні умова допуску, уповноважений на зміну компонент, збережений запис і визначена дія за відсутності підтвердження.

Усуньте розрив між комітом бази й надсиланням події

Перевірити баланс і пізніше оновити його — недостатній захист від одночасних операцій. Документація MySQL щодо читання з блокуванням пояснює, чому звичайне читання не захищає пов'язані записи. У локальній транзакції використовуйте відповідні оновлення з перевіркою умов або блокування й обмеження унікальності, щоб захищати справжні інваріанти грошей і ставок. Робіть транзакції короткими: мережевий виклик провайдера не має невизначено довго утримувати блокування запису гаманця.

Наступний розрив — надсилання події: ставку записано комітом, потім процес припиняється, не повідомивши залежні сервіси. Записуйте зміну ставки та вихідну подію в одній локальній транзакції, а надсилайте збережені комітом події окремо. Патерн транзакційного outbox описує цей підхід і потребу в стійких до повторів отримувачах.

Для B71 вихідний факт має бути конкретним: ставку прийнято, вказано її версію та прийняті умови. Перезапуск відправника може призвести до повторної доставки. Якщо гаманець — окрема система, така подія або надійно збережена команда можуть запитувати списання наявного резерву зі стійким ідентифікатором грошової операції. Гаманець має обліковувати обробку повторів разом із грошовим ефектом: позначка «оброблено» до ефекту або після нього в непов'язаній транзакції залишає ще один розрив у разі збою.

Outbox не перетворює віддалений гаманець і базу ставок на одну транзакцію. Показуйте незавершені передачі, повторюйте операції за погодженим контрактом і звіряйте результати. Застосунок має вміти відповісти, чи прийнята й оплачена B71, навіть якщо лист із повідомленням або представлення для звітності ще не оновилося.

Подайте розрахунок як послідовність облікованих операцій

Відокремте отримання спортивних результатів від розрахунку ставок. Провайдер повідомляє факти про подію, ринок або вибраний результат; компонент розрахунку зіставляє їх із прийнятими ставками й застосовує відповідні правила. Йому потрібні початкові параметри ринку, а не лише відображена назва. Результати, що надійшли до запізнілого підтвердження прийняття, потрібно зберігати й зіставляти, а не відкидати через те, що локальна ставка досі очікує рішення.

Використовуйте досить точний ідентифікатор операції, щоб відрізняти застосування результату від його виправлення. Він може включати локальну ставку й версію розрахунку, окремо зберігаючи підтверджувальні дані та ідентифікатори постачальника. Точна схема залежить від контракту провайдера. Не вважайте часову позначку повідомлення універсальним номером версії з глобальним порядком.

Виправлення входять до моделі. Наприклад, документація Sportradar щодо скасування розрахунків UOF описує скасування помилкового розрахунку, зокрема на рівні вибраного результату. Зберігайте початкове застосування, дозволене сторнування й можливу заміну; поточний відображений статус має бути представленням цієї історії. Для B71 повторна доставка того самого сторнування не має знімати ще 60.

Якщо зараховані кошти клієнт витратив або вивів до виправлення, простий приклад уже не описує його поточного балансу. Усуньте розбіжність за затвердженою політикою оператора для рахунків і порядком розгляду випадків. Не видаляйте початковий запис і не приховуйте дефіцит зміною відображеного балансу.

Інженерна команда не може вигадувати правила ставок. У Великій Британії рекомендації Gambling Commission щодо опублікованих правил охоплюють приймання й розрахунок, включно зі скасуваннями, помилками та визначенням результату. Використовуйте їх у межах цієї юрисдикції; погодьте фактично застосовні вимоги з оператором і кваліфікованими консультантами. Ширша модель обліку розглядається в матеріалі про проєктування гаманця та реєстру транзакцій.

Масштабуйте пропозицію, зберігаючи надійність грошових операцій

Перегляд пропозицій та остаточне приймання мають різні вимоги до узгодженості. Каталог коефіцієнтів може використовувати кешовані представлення для багатьох відвідувачів. Приймання має перевіряти відповідний поточний стан пропозиції, право клієнта робити ставки, кошти й контроль ризику в точці остаточного рішення. Швидкий, але застарілий каталог не дає підстав приймати ставку на призупинений результат.

Розділяйте обробку за справжніми областями конкуренції: гроші клієнта, переходи ставки або група зобов'язань, що обмежує конкретний ризик. Ключ черги може допомагати зберігати порядок обробки в межах області, але коректність усе одно залежить від захищених перевірками записів і справжніх правил порядку повідомлень провайдера. Уникайте однієї глобальної черги, у якій активний матч затримує непов'язану роботу. Не вважайте всі події різних джерел зіставними лише тому, що вони мають часові позначки.

Для відновлення фіду та ставки потрібні різні підтвердження. Документація щодо відновлення UOF пояснює, що під час відновлення можуть надходити поточні коефіцієнти замість усіх проміжних змін і можуть об'єднуватися повідомлення про розрахунок. Повторне формування каталогу не відновлює прийнятий коефіцієнт B71 або її грошову історію.

Під час інциденту на події зупиніть нове приймання в ураженій області, якщо дані або контроль не дають змоги ухвалити допустиме рішення. Зберігайте обробку прийнятих ставок, перевірку статусу й фінансове звіряння, де це дозволяють залежності. Повторне відкриття потребує виконання умов відновлення та локального застосування даних для цієї інтеграції. Навантажувальні перевірки мають включати активну подію, повільного провайдера й масове надходження результатів, а не лише анонімні перегляди сторінок. Питання потужності розбираємо в матеріалі про масштабування за пікового трафіку й подій у реальному часі.

Перевірте архітектуру на сценаріях збоїв і відновлення

Перевіряйте архітектуру, навмисно перериваючи B71 між збереженими кроками. Зупиніть процес після резерву, зовнішнього прийняття, коміту ставки й зарахування гаманцем. Для кожного переривання визначте записи, що залишилися, і компонент, якому дозволено продовжити. Якщо відповідь — «підтримка змінює статус, доки все не виглядає правильно», проєктування відновлення не завершене.

Контракт повтору має визначати, який ідентифікатор зберігається, що відбувається в разі зміни параметрів і як розпізнаються запізнілі запити. Матеріал Amazon Builders' Library про ідемпотентні API розглядає ідентифікатори від відправника, конфлікти параметрів і запізнілі запити. Для букмекерської платформи задавайте строк зберігання за справжніми потребами провайдера й відновлення; завершення строку короткочасного кешу не має створювати розраховану ставку знову.

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

До виокремлення нових сервісів підтвердьте чотири перевірки нижче й виміряйте виявлену ними незавершену роботу. Невелика система з надійним відновленням — міцніша основа, ніж багато сервісів, часткові збої яких неможливо пояснити. Реалізацію на боці інтеграцій постачальників розглядаємо в матеріалі про межі інтеграційного шару й адаптери.

Двом розширенням потрібні власні межі. У платформі з кількома брендами чітко вкажіть область оператора й гаманця в ставках, конфігурації та ідентифікаторах запитів: керувальна дія одного бренду не має випадково впливати на інший. Якщо продукт включає віртуальну економіку, окремо визначте правила її валют і винагород. Спільний інтерфейс облікового запису не дає підстав вважати віртуальні нагороди взаємозамінними з коштами букмекерського гаманця.

• Перервіть приймання після рішення провайдера, але до збереження локальної відповіді. Відновіть той самий запит і підтвердьте узгодженість відомої ставки, її резерву й подальшої оплати без створення другої ставки.
• Виконайте коміт ставки й зупиніть відправника подій до публікації; потім знову зупиніть його після публікації, але до підтвердження. Підтвердьте подальшу доставку без повторної оплати ставки або іншого грошового ефекту.
• Застосуйте результат, повторіть його обробку, потім дозвольте виправлення й повторіть обробку виправлення. Звірте точний підсумковий рух і збережіть усі пов'язані операції; покажіть контрольований порядок дій, якщо кошти вже витрачено.
• Повторно сформуйте представлення для читання й відновіть повідомлення фіду, поки ставки очікують рішення та надходять результати. Підтвердьте збереження прийнятих умов і грошової історії, збереження ще не застосованих обґрунтованих результатів та відкриття лише допустимих пропозицій.