Кілька брендів iGaming: спільне ядро та чіткі межі

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

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

Розділіть бренд, орендаря та юридичну особу оператора

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

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

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

Огляд можливостей платформи допомагає визначити продуктову область. Посібник із меж доменів пояснює відповідальність усередині неї. Тут додаткове питання — на якого орендаря чи бренд може впливати кожне рішення.

Оберіть модель ізоляції для кожного ресурсу

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

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

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

Якщо обрано PostgreSQL, політики рядків можуть додати межу на рівні даних. Документація із захисту рядків вказує, що суперкористувачі й ролі з BYPASSRLS обходять ці політики; власники таблиць зазвичай також. Перевіряйте фактичну роль застосунку, а не лише визначення політики. Це особливість конкретної бази, а не твердження, що кожна платформа чи цей проєкт використовує PostgreSQL.

Передавайте перевірений контекст усіма шляхами доступу

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

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

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

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

Керуйте конфігурацією як випуском продуктової зміни

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

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

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

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

Пов’яжіть пізні повідомлення провайдера з початковою областю

Розгляньмо бренди «Північ» і «Південь». У прикладі кожен має свого гравця під номером 47 і свій торговий обліковий запис у провайдера. Договір провайдера визначає номери операцій усередині кожного такого запису. Тому обидва облікові записи можуть коректно повідомити про операцію 707, маючи на увазі різні транзакції.

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

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

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

Захистіть ресурси й відновлення всього портфеля

Бренд може бути ізольований за даними й усе одно порушувати обслуговування іншого бренду. Акція здатна зайняти спільні обробники, звіт — з’єднання з базою, а кілька брендів — використовувати одну квоту постачальника. Окремі екземпляри застосунку не ізолюють спільної фінансової бази або зовнішнього ліміту торгового облікового запису.

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

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

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

Перевірте наступний бренд до відкриття доступу

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

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

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

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

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