Ви оплатили покупку, але сайт не показав підтвердження. Натиснули кнопку ще раз — і гроші списалися двічі. Таке може статися, коли платіж уже пройшов, а повідомлення про нього затрималося між серверами. Велика цифрова система складається з багатьох частин, розкиданих по різних куточках планети, і спілкуються вони між собою подіями — сигналами про те, що щось сталося: натиснута кнопка, надісланий платіж, оформлена заява. Спільного "зараз" для цих подій не існує.
Такі системи щодня проводять мільярди операцій для десятків мільйонів американців — оплату підписок, страхові виплати, покази реклами. Коли щось у цьому ланцюжку йде не за планом, ціна помилки вимірюється грошима: подвійним списанням, втраченою виплатою чи недоставленим рекламним контрактом.
Цю задачу вирішує Артем Іпатов — backend-інженер, який будує системи обробки подій у реальному часі: спершу для одного з найбільших страховиків США, а сьогодні — для рекламної інфраструктури великої американської медіаплатформи.
Під словом "сервіс" мається на увазі те, чим користується людина: застосунок банку, стримінговий сервіс або онлайн-магазин. "Система" — це його невидима начинка: програми на серверах, які обмінюються сигналами, щоб для користувача все виглядало як одна кнопка й один екран.
Чому різні частини сервісу бачать подію в різний час
Коли ви натискаєте "оплатити" у застосунку, запит проходить через кілька частин системи, схованої під ним. Одна перевіряє картку, друга списує кошти, третя змінює статус замовлення, четверта надсилає підтвердження. Вони отримують інформацію неодночасно, тому платіж уже може відбутися, хоча сайт ще показує замовлення неоплаченим.
Ще одна пастка, яку Артем враховує в кожному проєкті, — час на самих серверах. У кожного з них власний годинник, і хоч їх регулярно синхронізують, невелика різниця залишається. Тому позначка часу в повідомленні не доводить, яка дія сталася першою.
"Система може спочатку отримати команду відправити товар, а вже потім — підтвердження оплати. Повідомлення просто йшли різними маршрутами, і одне дісталося швидше, — пояснює Артем. Якщо довіритися цьому порядку наосліп, магазин почне відвантажувати неоплачене"
Тому для Артема головне — місце події в ланцюжку. Він проєктує системи так, щоб кожна операція знала, після якої іншої їй дозволено виконатися: замовлення не піде на відправлення без підтвердженої оплати, а страхову виплату система не проведе до завершення перевірки заяви. Що більше в платформи користувачів і серверів, то частіше плутається порядок, і то важливіше закласти цю залежність заздалегідь.
Як не втратити страхову виплату
У 2020–2021 роках, ще в Харкові, Артем працював над системою для одного з найбільших страховиків США. Вона супроводжувала страхову заяву від реєстрації до рішення та виплати коштів. Для клієнта процес виглядає послідовним: він подає заяву, страхова компанія перевіряє обставини, ухвалює рішення та перераховує гроші. Усередині системи за ці етапи відповідають різні частини, які обмінюються повідомленнями.
Під час такого обміну подія може запізнитися, надійти двічі або опинитися не на своєму місці в черзі. Якщо система не врахує підтвердження, заява зупиниться і людина не отримає виплату вчасно. Якщо двічі виконає той самий сигнал, компанія ризикує повторити операцію.
Артем працював над механізмом повторної обробки таких подій. Якщо повідомлення надходило зарано, система не відкидала його. Вона зберігала сигнал і поверталася до нього після завершення попередніх етапів.
Повторні повідомлення теж треба було зробити безпечними. Кожна операція отримувала унікальний номер, за яким система могла перевірити, чи виконувала її раніше. Якщо той самий запит надходив знову, він не запускав другу виплату. Це називають ідемпотентністю: скільки б разів не надійшла команда, виплата пройде один раз.
Артем також передбачив додаткову перевірку для подій, які не вдалося обробити з першої спроби. Вона повторно знаходила такі випадки й повертала їх у роботу.
Робота над страховою системою стала для Артема поворотним моментом у ставленні до надійності. До backend-розробки він кілька років працював з іграми та мобільними застосунками, де технічна помилка передусім псує враження від продукту. У системі, яка супроводжує страхову заяву, та сама помилка означає, що людина не отримає гроші тоді, коли вони їй потрібні. Відтоді він підходить до кожної системи з одним і тим самим питанням: що станеться, коли щось піде не так.
Від обробки страхових подій Артем перейшов до інфраструктури показу реклами у стримінгу: спочатку в межах контракту з великою американською медіаплатформою, а з 2024 року на посаді в її команді безпосередньо. Масштаб тут інший: мова вже не про одну заяву, а про мільярди рекламних показів щодня для мільйонів американських глядачів.
Коли система працює, але результат неправильний
Зазвичай про збій дізнаються одразу: сайт не відкривається чи з'являється помилка. Але деякі збої так себе не проявляють. На перший погляд усе в нормі, а система все одно видає неправильний результат.
Один такий випадок Артем знайшов сам, хоча скарг не було. У рекламі ролики іноді продають ланцюжком: якщо показали перший, решта показуються обов'язково. Система ж рахувала ціну кожного ролика окремо. Через це ланцюжок міг програти відбір дешевшій поодинокій рекламі, хоча разом коштував більше. Система продовжувала працювати без жодного попередження, хоча цифра на виході була неправильною. Артем змінив розрахунок так, щоб ланцюжок оцінювався цілком, і відбір почав відображати реальну вартість.
Щоб знаходити такі помилки, Артем побудував окремий сервіс для команди, у якій працює сьогодні. Він порівнює показники доставки з різних джерел і показує розбіжності. Перевірку виконує програма, не пов'язана з тією, що формує самі дані: якби дані контролювала та сама система, що їх рахувала, вона повторила б власну помилку. За цю розробку компанія відзначила Артема внутрішньою нагородою.
Значення таких перевірок зростає з масштабом. Сьогодні один із сервісів рекламного стека, з якими працює Артем, обробляє близько 65 тисяч запитів за секунду. За такого навантаження навіть рідкісна помилка повторюється тисячі разів. Для користувача це може означати проблему з входом чи оплатою, для рекламодавця — недоотримані покази, для платформи — втрату доходу, яка в масштабах американської рекламної індустрії вимірюється мільйонами доларів щороку.
Що таке насправді "реальний час"
"Реальний час" звучить так, ніби все відбувається миттєво для всіх. Артем пояснює, що це означає інше: система встигає отримати й обробити інформацію за час, прийнятний для конкретного завдання.
Для показу реклами це частки секунди. Статус замовлення може оновлюватися кілька секунд. Фінансова операція іноді потребує більше часу, бо система має провести додаткові перевірки.
Тому швидкість — лише частина завдання. Якщо платформа миттєво видає неправильний результат, надійною її назвати не можна. Система має розуміти послідовність дій, безпечно повторювати запити та знаходити операції, які не завершилися.
Ці механізми й створює Іпатов: його завдання — зробити так, щоб сотні серверів працювали для користувача як одне ціле. Людина може не знати, скільки сигналів пройшло між ними, але має отримати однозначний результат: одну оплату, правильний статус і вчасну виплату.
1 
4069
Коментарі