О 9:29:55 у торговий день на фондовому ринку США кілька інженерів розподілених систем у великих біржах і кожному банку першого рівня вдивляються в панелі моніторингу, які вони, мабуть, розглядають уже роками. П'ять секунд по тому фондові ринки країни поглинають пікове замовлення, що може перевищувати п'ятсот тисяч повідомлень на секунду по консолідованій стрічці. Системи, які поглинають цей сплеск, є одними з найбільш ретельно спроектованих програмних продуктів у комерційному використанні, а патерни, на які вони спираються, тепер забезпечують роботу більшої частини решти фінансового сектору США.
Що насправді означає «розподілений» у контексті фінансів США
Розподілена система, у підручному розумінні, — це набір процесів, що взаємодіють через мережу для надання єдиного узгодженого сервісу. У контексті фінансів США визначення звужується. Це означає сервіс, де стан зберігається в кількох місцях, затримка вимірюється в мікросекундах, а режими збоїв не є теоретичними, оскільки регулятор може запросити аналіз наслідків протягом сорока восьми годин.
Класичними прикладами є механізм зіставлення ордерів біржі, перемикач платежів у реальному часі, сервіс оцінки шахрайства та мережа розповсюдження ринкових даних. Кожен із них має дещо різні вимоги до узгодженості. Механізм зіставлення ордерів потребує суворого впорядкування. Система виявлення шахрайства надає пріоритет швидкості над повнотою. Мережа розповсюдження ринкових даних прагне до пропускної спроможності. Інженерні рішення випливають із цих обмежень.
Причина, чому це важливо зараз, у 2026 році, полягає в тому, що ті самі архітектурні патерни перемістилися з торгових відділів у решту фінтех-індустрії США. Споживчий платіжний застосунок, платформа банку-спонсора BaaS та продукт дохідності казначейства — усі вони тепер працюють на розподілених архітектурах, які десять років тому вважалися екзотичними.
Як сьогодні будуються найбільші фінансові системи США
Три архітектурні патерни повторюються майже в кожній серйозній розподіленій фінансовій системі США. Перший — це джерело подій (event sourcing), де кожна зміна стану спочатку записується до журналу з доданням записів, а матеріалізовані представлення виводяться з цього журналу. Kafka, AWS Kinesis та Confluent Cloud тепер лежать в основі більшості великих фінтех-бекендів із вікнами зберігання, достатньо великими для відтворення днів або тижнів активності. Переваги для аудиту та звірки накопичуються; для багатьох офіцерів з відповідності журнал є джерелом істини.
Другий — це консенсус і реплікація. Більшість фінтех-баз даних тепер працюють на протоколах, що походять від Raft або Paxos. CockroachDB, FoundationDB, Spanner та основні хмарні реєстри — усі використовують варіанти. Практичний ефект полягає в тому, що одна транзакція у фінтеху США може витримати втрату цілої зони доступності без втрати даних і з кількома секундами простою, що раніше вимагало місяців інженерних робіт.
Третій — це сервісна сітка та маршрутизація з урахуванням швидкості. Envoy, Istio та Linkerd тепер є стандартом, а конфігурації, що використовуються у фінансах, спираються на розривники кола, бюджети повторних спроб та патерни перегородок, успадковані з посібника Netflix. Платіжні рейки США, якими користуються фінтехи, найчастіше розташовані за цими сітками.
Таблиця показників продуктивності розподілених систем у фінансах США
Наведені нижче цифри отримано зі зведення публічних інженерних блогів, звітів SOC 2 постачальників і розкритих історій інцидентів. Вони окреслюють корисну базову лінію того, чого насправді досягають виробничі розподілені системи у фінансах США.
Найбільш показовою є лінія затримки p99. Десять років тому субмілісекундний p99 був числом лише для торгівлі. Сьогодні кілька фінтехів США, орієнтованих на споживачів, публікують затримки p99 в одноцифрові мілісекунди для основних потоків автентифікації та ініціації платежів. Вартість досягнення цього є значною, але операційна вартість підтримки нижча, ніж вартість роботи повільнішої системи, оскільки інциденти за фінансових затримок дорого обходяться для розслідування.
У межах регульованих стін банку США команда розподілених систем зазвичай підпорядковується двом господарям. Платформна організація дбає про час безперебійної роботи, пропускну спроможність і операційні витрати. Організація з управління ризиками та відповідності дбає про можливість аудиту, незмінність і доказовість. Архітектури, що виникають, зазвичай є компромісом: журнали подій із доданням записів для задоволення другого господаря, матеріалізовані представлення запитів і кеші — для задоволення першого.
Режими збоїв, що досі завдають шкоди фінтехам США у виробничому середовищі
Три режими збоїв становлять більшість виробничих інцидентів фінтехів США за останні два роки, на основі розкритих звітів про інциденти та підсумків аналізу наслідків. Перший — це каскадні повторні спроби. Тайм-аут нижнього за потоком сервісу запускає шторм повторних спроб на сервісі вище за потоком, який вичерпує пул з'єднань, що поширюється назад як видимий клієнту збій. Бюджети повторних спроб і розривники кола є стандартним засобом пом'якшення, але кожна інженерна команда засвоює це важким шляхом принаймні один раз.
Другий — це «розщеплений мозок» у багатьох регіонах. Коли мережевий розділ відрізає основний регіон фінтеху від його репліки, наївний код аварійного перемикання може призначити обидві сторони лідером. Результатом є розбіжні записи, які потрібно узгоджувати вручну. Дизайни на основі CRDT та консенсусу є вирішенням, але їх впровадження нерівномірне.
Третій — це прогалини в спостережуваності. Більшість збоїв фінтехів спричинені не відмовою одного компонента ізольовано; вони спричинені ланцюжком невеликих деградацій, які жодна окрема панель моніторингу не відображає. Команди, які серйозно інвестують у розподілене трасування, кореляцію журналів і метрики з урахуванням кардинальності, як правило, виявляють і вирішують інциденти в два-три рази швидше, ніж ті, що цього не роблять. Дисципліна навколо платіжної інфраструктури на основі ACH часто сприяє цій зрілості, оскільки звірка не прощає помилок.
Культурний аспект роботи розподілених систем у фінансах недооцінюється. Команди, що підтримують низький рівень інцидентів, майже завжди проводять аналіз наслідків без звинувачень, публікують посібники з експлуатації, які інженери справді читають, і чергують чергування, що захищають старших інженерів від хронічного недосипання. Одні лише інструменти ніколи не компенсують крихку культуру чергування; багато з найгучніших збоїв фінтехів США за останні три роки сягали корінням у культурну проблему задовго до того, як спрацьовував сигнал тривоги.
Що це означає для засновників фінтехів, що будують інфраструктуру сьогодні
Для засновників фінтехів США практичний наслідок полягає в тому, що вартість неправильного проектування розподілених систем знизилася лише на найранішому етапі. Прототип на стадії пре-сід на керованому Postgres і в одному регіоні AWS — це нормально. Як тільки продукт має реальні кошти клієнтів у русі, інженерна планка різко зростає, а команди, які відкладають цю розмову, втрачають або час безперебійної роботи, або клієнтів, або і те, і інше.
Три питання, на які кожен засновник фінтеху повинен вміти відповісти щодо власної архітектури до моменту досягнення фінансування серії А: що станеться, якщо основна база даних буде недоступна протягом десяти хвилин; що станеться, якщо партнер нижнього за потоком повертає 500 протягом тридцяти секунд; і як система тестується для цих сценаріїв. Засновники, які можуть чітко відповісти на всі три, як правило, масштабуються через точки перегину, що ламають їхніх колег.
Аспект найму також є конкретним. Старший інженер розподілених систем у фінтеху США у 2026 році отримує загальний компенсаційний пакет у верхній частині ринку технологій США, часто понад триста п'ятдесят тисяч доларів для когось із досвідом у платежах або торгівлі. Пропозиція обмежена, оскільки набір досвіду займає десятиліття для формування. Банківські інновації, що масштабуються глобально, майже завжди мають принаймні одного такого інженера серед перших десяти найманих співробітників.
Географічна концентрація обчислень є ще одним непомітним ризиком. Дивовижна кількість фінтехів США виконує свої основні робочі навантаження в одному регіоні AWS (часто us-east-1), що означає збій Amazon у північній Вірджинії безпосередньо перетворюється на збій фінтеху США. Мультирегіональний режим активний-активний є технічно складним і дорогим, але команди, що інвестували в нього, мають суттєво інший профіль інцидентів.
Постачальницький ландшафт, що підтримує все це, консолідувався. Основні хмарні провайдери (AWS, Google Cloud та Azure) тепер пропонують еталонні архітектури, специфічні для фінансових послуг, а регіональні банки-спонсори почали публікувати власні. Ландшафт відкритого програмного забезпечення (Kafka, Redis, ClickHouse, Postgres, Temporal) достатньо зрілий, щоб новий фінтех міг випустити свій V1 на стеку, який у 2018 році вимагав би індивідуальної розробки.
Відкриття о 9:30 ранку продовжуватиме бути стрес-тестом для найвимогливішого програмного забезпечення країни. Цікавим розвитком є те, що та сама інженерна строгість тепер помітна всередині фінтехів, які ніколи не наближаються до біржі.
Для одного прикладу протоколів дротового зв'язку, описаних вище, дивіться специфікацію загального клієнта NYSE Pillar.
