Здравствуйте, ·, Вы писали:

S>>О да. Двадцать миллисекунд придётся подождать.
·>Для FX-трейдинга — задержка 20мс — это production issue. Типичная latency — 0.3мс.
К счастью, FX-трейдинг — нишевая штука. Нафиг не нужен никому, кроме спекулянтов.
Поэтому рассматривать его требования как основу архитектуры типичного бизнес-приложения не нужно.

S>>Если мы отменяем этот инвариант, придётся переделывать примерно всё.
·>Так ведь у нас уже есть бизнес-сущность "частично зарезервированный заказ". Поэтому уже неважно — на 99.9% или на 0.1% зарезервированный. Алгоритмы будут те же.
Не факт. У нас рассуждения дошли до того, что мы можем разделить заказ на два заказа, одновременно сохраняя базовый инвариант, и обходя ограничения строго-атомарного резервирования.

·>Батчинг — это уже ортогонально бизнес-требованиям, это нефункциональное требование. Можно батчами обрабатывать входные заявки на резервацию.
Нет, вы не поняли. Батчинг тут не про несколько заявок, а про то, что одним стейтментом можно поменять произвольное количество "строк".

·>Это скорее про поточную, конвеерную обработку. Когда идут потоки сообщений туда-сюда, друг друга не мешая, с минимальными блокировками.
Я не умею работать с потоками сообщений. Что такое state мне понятно; вместе со всеми производными понятиями — когерентность, распространение, согласованность, несогласованность.
Что можно сказать про систему на потоках сообщений — да хз. Какие-то сообщения куда-то едут. Соответствует ли такая система каким-нибудь требованиям? Может и соответствует. Как это доказать — непонятно.

S>>Редчайший случай, заказ на тысячу позиций. Какого характерного размера это "гигантское" сообщение? В непожатом JSON оно будет занимать полсотни килобайт. Семечки.
·>В высокопроизводительных системах — порядка сотен байт.
Вы говорите о системах, в которых производительность возведена в кумиры, и ей в жертву приносят всё, включая здравый смысл.
Нет, я не против — мне самому очень нравится архитектура LMAX Disruptor. Но не как задача, которую решают пацаны, а как способ посмотреть на задачу под другим углом.

А в традиционном бизнесе нет нужды опередить соперника на долю наносекунды. Зато важно, чтобы инварианты не разъехались.