WebAssembly внутри Tarantool: как вынести бизнес-логику с TX-потока, не разрывая транзакцию

Tarantool выполняет Lua-код и операции с данными на TX-потоке с кооперативной многозадачностью. Если поместить туда тяжёлый скоринг или движок бизнес-правил, один запрос может задержать обработку остальных. Вынесение алгоритма в отдельный сервис решает проблему конкуренции за CPU, но добавляет RPC, новый сценарий отказа и усложняет атомарную работу с данными.

В докладе рассмотрим другой вариант: запуск WebAssembly Component Model внутри Tarantool. Компонент выполняет тяжёлую часть вычисления на worker-потоке, а доступ к spaces, indexes и transactions получает через версионированный WIT-контракт. После начала транзакции выполнение возвращается на TX-поток, где остаётся только короткая критическая секция.

Разберём работающий пример авторизации платежа: расчёт score, контроль версии политики, защита от повторной обработки request_id, резервирование средств и запись события в outbox. Покажем, как система ведёт себя при конкурентном повторе запроса, устаревшем снимке данных, исчерпании fuel, отмене вычисления и аварии компонента после начала транзакции. Сравним решение с эквивалентной реализацией на Lua. На последовательном тесте WebAssembly добавил примерно 1,4–1,9 мс медианной задержки, но в CPU-intensive сценарии сохранил p99 задержки TX heartbeat около одной миллисекунды, тогда как Lua блокировал TX-поток примерно на 300 мс. Обсудим, когда такой обмен оправдан, а когда лучше оставить Lua или использовать отдельный сервис.