Несколько брендов iGaming: общее ядро и чёткие границы

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

Руководство предназначено для операторов, руководителей продукта и архитекторов, решающих, как нескольким брендам использовать общую платформу. Оно отделяет общую реализацию от общих полномочий над бизнес-решениями и предлагает способ проверки данных, конфигурации, провайдеров и эксплуатационных ресурсов. Разбор двух брендов условный: в нём предполагаются отдельные кошельки игроков и торговые учётные записи у провайдера, а не рекомендуется объединять балансы или юридическую ответственность.

Разделите бренд, арендатора и юридическое лицо оператора

Начните с явной карты отношений. Бренд — это предложение для игрока. Арендатор — область, внутри которой платформа управляет ресурсами и разрешениями. Юридическое лицо оператора отвечает за фактический бизнес. Рынок, лицензия, среда и учётная запись провайдера добавляют другие измерения. Между ними не обязательно существует связь один к одному.

Один оператор может вести несколько брендов внутри одного арендатора, ограничивая сотрудников по бренду. Платформе для разных операторов может потребоваться изоляция арендаторов над уровнем брендов. Запишите, к какому уровню относятся идентификационные данные, аккаунты, кошельки, ограничения и записи отчётности. Распознавание одного человека в разных брендах автоматически не создаёт общий игровой аккаунт или доступный для расходования баланс. И наоборот, обязательное ограничение на уровне группы не должно обходиться из-за того, что бренды считаются несвязанными.

Оператор и квалифицированные консультанты должны установить применимые требования рынка, договоров, защиты игроков и обмена данными. Инженеры реализуют утверждённую область, а не выводят разрешение из общего владения. Если сопоставление личности между брендами разрешено, определите его цель, доступ и последствия; не раскрывайте полный профиль игрока по всему портфелю каждому сотруднику поддержки.

Обзор возможностей платформы помогает определить продуктовую область. Руководство по границам доменов объясняет ответственность внутри неё. Здесь дополнительный вопрос — на какого арендатора или бренд может влиять каждое решение.

Выберите модель изоляции для каждого ресурса

Общий код не требует общего хранилища или единого развёртывания. Выберите границу каждого ресурса, определив, что нужно разделить и какой сбой может затронуть другой бренд.

• Общие ресурсы: бренды используют общие ресурсы приложения или хранилища с принудительным ограничением логической области. Это может упростить общие обновления и использование ресурсов, но требует надёжных границ доступа и контроля нагрузки.
• Выделенные ресурсы: арендатор или бренд получает отдельные базы, обработчики либо более полную среду. Это может сузить некоторые сбои и упростить часть границ, увеличивая работу по подготовке, миграции и эксплуатации. Общий административный доступ и внешние зависимости всё равно требуют проверки.
• Смешанная модель: оставьте подходящие возможности общими, а ресурсы, которым нужна более строгая граница, выделите. AWS описывает такое сочетание как смешанную модель изоляции; решение можно принимать для отдельных ресурсов, а не всей платформы.

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

Если выбран PostgreSQL, политики строк могут добавить границу на уровне данных. Документация по защите строк указывает, что суперпользователи и роли с BYPASSRLS обходят эти политики; владельцы таблиц обычно тоже. Проверяйте фактическую роль приложения, а не только определение политики. Это особенность конкретной базы, а не утверждение, что каждая платформа или этот проект использует PostgreSQL.

Передавайте проверенный контекст по всем путям доступа

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

Руководство OWASP по безопасности нескольких арендаторов разделяет выбранный клиентом контекст и проверенные сервером полномочия. Применяйте это различие к поиску игрока, денежным командам и маршрутизации провайдера: доступ должен соответствовать и области вызывающей стороны, и целевой записи.

Проследите контекст за пределами веб-запроса. Определите, какие записи кеша, документы, результаты поиска, отчёты и сообщения зависят от бренда или арендатора, и проверьте пути доступа к ним. Публичные справочные данные могут намеренно использоваться совместно; защищённая выгрузка игроков требует другой границы. Повторное использование соединения с базой или обработчика не должно переносить область другого запроса.

Доступ сотрудников ко всему портфелю должен иметь явную идентичность, цель и набор разрешений. Обзор бэк-офиса помогает определить работу; руководство по правам сотрудников и аудиту раскрывает контролируемые действия. Отчёт по нескольким брендам не даёт права исправлять записи во всех них. Для чувствительных изменений фиксируйте исполнителя, затронутую область, необходимое одобрение и сохранённый результат.

Управляйте конфигурацией как выпуском продуктового изменения

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

• Явно определяйте результат: опишите поддерживаемые уровни значений по умолчанию и переопределений, например платформу, арендатора, бренд и рынок. Покажите итоговую конфигурацию до публикации. Отсутствующие учётные данные провайдера или обязательное правило не должны незаметно наследовать небезопасное общее значение.
• Проверяйте сочетания: совместно проверяйте валюты, учётные записи провайдеров, разрешённые каталоги и зависимые функции. Переключатель может открыть возможность, которую окружающий процесс не поддерживает.
• Публикуйте версию: сохраняйте предлагаемое изменение, различия, одобрившего сотрудника, момент активации и план восстановления. Применяйте нужную инвалидацию кеша и проверяйте целевую область, а также незатронутые бренды.
• Сохраняйте принятые условия: отделяйте правила новой активности от доказательств, объясняющих уже принятую работу. Сохраняйте ссылку на соответствующую конфигурацию или политику там, где она нужна процессу; не переписывайте историю при смене настройки.

Предпочитайте проверенные механизмы настройки отдельной копии кода для каждого бренда. Такая копия может создать впечатление дешёвой доработки для бренда, но привести к расхождению будущих исправлений. При этом система конфигурации не должна становиться неограниченным языком программирования. Если брендам нужны несовместимые правила транзакций или независимые обязательства по релизам, пересмотрите границу домена или развёртывания вместо накопления скрытых исключений.

Возврат настройки меняет будущее поведение по согласованным правилам. Он не отменяет принятую ставку, не завершает ожидающий платёж и не устраняет необходимость объяснить решение, принятое при прежней версии.

Свяжите поздние сообщения провайдера с исходной областью

Рассмотрим бренды «Север» и «Юг». В примере у каждого свой игрок под номером 47 и своя торговая учётная запись у провайдера. Договор провайдера определяет номера операций внутри каждой такой записи. Поэтому обе учётные записи могут корректно сообщить об операции 707, имея в виду разные транзакции.

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

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

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

Защитите ресурсы и восстановление всего портфеля

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

Измеряйте спрос и незавершённую работу в значимых границах: арендатор, бренд, процесс и учётная запись провайдера. Согласуйте распределение ресурсов, общие лимиты сервиса и условия для выделенных обработчиков или других ресурсов. Проверяйте всплеск одного бренда, пока другой выполняет необходимые процессы. Сохраняйте ресурсы для принятой денежной работы, не позволяя необязательным выгрузкам доминировать при восстановлении. Руководство по пиковой нагрузке раскрывает планирование приёма и завершения работы.

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

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

Проверьте следующий бренд до открытия доступа

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

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

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

Для последовательности работ и решений о запуске продолжите с планированием нового iGaming-продукта. Для постановки проверки и получения пригодных решений используйте результаты исследования и архитектурного спринта. Если бренд включает ставки, руководство по архитектуре букмекерской платформы объясняет состояния купона, кошелька и расчёта, которые граница бренда должна сохранять.

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