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

S>·>Так ведь по большому счёту разница невелика с т.з. усилий на разработку. А перформанс, он и в африке перформанс.
S>Разработка — она и в африке разработка. А вот проектирование...
... часть разработки.

S>·>Не понял, что именно "не факт".
S>Не факт, что мы смирились с заказами в "смешанном статусе" как с первоклассным состоянием системы.
Что за смешанный статус? Есть "начали резервацию", "закончили резервацию".

S>·>Это я плохо объяснил. Батчинг — это не требование бизнеса, а механизм повышения перформанса. Это когда запрос в субд на резервацию одной строки и ста строк занимает примерно одно и то же время, т.к. бОльшая часть времени уходит на всякие накладные расходы взаимодействия сервиса резервации и субд.
S>Про этот батчинг я ничего не говорил. Я говорил про семантику объединения операций в ACID-группу и техническую реализацию такой семантики.
Не понятно тогда зачем тебе именно надо в данной задаче объединять операции в одну ACID-группу. Из обоснований я пока заметил лишь: "SQL прекрасен батч-операциями".

S>·>Следовательно, выгоднее отправлять стейтменты всегда по 100 штук, вне зависимости от того, разные это заказы или один большой.
S>Не совсем. Если вы попробуете сделать 1 коммит на пачку заказов, то в случае неудачи откатится вся транзакция, включая и те заказы, которым всего хватает.
Мы вроде рассматриваем вариант "просто добавляется ещё один предикат во where". Неудача и откат тут будет лишь в случае системной ошибки.

S>·>Т.е. вначале разеделяем заказы на мелкие сообщения резервации, сообщения (возможно батчами) засылаем в очередь. Эта очередь потом разгребается (возможно батчами) и ответы отсылаются таким же способом. Ответы резервации аггрерируются в суммарный статус заказа.
S>Увеличиваем латентность, уменьшаем throughput.
Почему уменьшаем?? Для мелких ордеров throughput увеличится засчёт уменьшения числа раундтрипов.

S>·>Что-то вроде многопоточки, асинхронное программирование?.. Акторы?..
S>Ага. Вот мы сейчас изобретаем некоторый способ проектировать подобные системы так, чтобы потенциальные лайвлоки ловить не в продакшне, а в дизайн-тайме.
S>Что-то мне подсказывает, что у вас такого способа нет
Ах, вспомнил. Ты же говорил — workflow, который у тебя уже есть всё равно. Вот его и достаточно. Машина состояний, реагирует на сообщения, меняет внутреннее состояние, посылает сообщения.

S>·>Это по сути как реальность работает на низком уровне. REST-запрос — это два коррелированных сообщения запрос-ответ. А если не ограничиваться этим, то можно слать сообщения куда-то, и как-то реагировать на ответы откуда-то.
S>Ну так как только мы перестаём "ограничиваться", так сразу теряем всю привычную REST-семантику с её гарантиями.
"привычную" — ключевое слово.

S>·>Ну в трейдинге тоже ничего разъезжаться не должно. Если разъедится — дело дрянь и серьёзные убытки.
S>В трейдинге инварианты значительно более простые.
Трейдинг он разный..