Міграція iGaming за Strangler Fig: передайте відповідальність і вимкніть старий шлях

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

Опис Strangler Fig Мартіна Фаулера пояснює поступову заміну керованих частин і тимчасову архітектуру для спільної роботи старого та нового. На чинній iGaming-платформі практичне завдання — передати обмежену функціональність, не втративши прийнятої роботи й не створивши другого джерела фінансових змін.

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

Виберіть частину платформи й визначте, що залишиться

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

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

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

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

Контролюйте кожну точку входу на межі заміни

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

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

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

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

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

Збережіть явного відповідального за незавершені операції

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

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

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

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

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

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

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

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

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

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

Доведіть спільну роботу до перенаправлення реальних запитів

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

Порівнюйте зміст, а не лише однаковий JSON. Чи залишається та сама операція невирішеною? Чи залишається заборонена дія забороненою? Чи може підтримка знайти той самий ідентифікатор провайдера? Документуйте навмисні відмінності, наприклад виправлене зіставлення статусів, із відповідальним за рішення. Непояснена фінансова розбіжність або розбіжність доступу блокує розширення; старий результат — доказ для дослідження, а не завжди правильна специфікація.

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

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

Проведіть перехід із двома різними планами відновлення

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

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

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

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

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

Вимкніть старий шлях і оцініть наступну частину

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

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

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

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

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

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