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

G>·>Пока ВНЕЗАПНО не наступает какая-нибдуь чёрная пятница или новогодние распродажи.
G>ВНЕЗАПНО длительность транзакции напрямую не влияет на масштабируемость систем. По сути все распределенные транзакции длительность увеличивают, но также увеличивают и пропускную способность.
А я и не предлагал распределённые транзакции.

G>>>- высокие требования к консистентности данных. потерять изменения в бизнес-приложении можно один максимум раз, после второго раза будет уже другой исполнитель. Это must-фактор. Нельзя иметь надежность ниже определенного уровня, в сценариях, которые встречаются на практике.
G>·>В трейдинге плюс к этому ещё и штрафы влепят от всяких FCA.
G>За что?
За неимение надёжности определённого уровня при предоставлении финансовых услуг.

G>·>Ээ, так ещё есть трейдинг по другую сторону баррикады. Например, сама биржа по сути те же заказы (orders) и склад (биржевой стакан). И продать больше — никак нельзя.
G>В на бирже чуть проще, там же ордеры по одному инструменту по сути уже сериализованы этим самым "стаканом".
Есть ещё mass order cancel/replace которые валят от market makers.

G>остается только инженерная задача распределения "стаканов" по сервакам так, чтобы максимизировать надежность и скорость записи (шардирование)
Круто наверное это твоё шардирование, особенно когда 95% трафика сыплет на какую-нибудь одну особо популярную сковородку типа EURUSD в первые секунды какого-нибудь очередного market event.

G>>> В трейинге по сути один сценарий — приход информации от биржи, а в результате надо выдать пачку ордеров
G>·>Ну вот по обсуждаемой теме есть ещё например portfolio/index трейдинг, где ордера бывают на десяток тысяч позиций. И сложные сценарии price negotiation, споттинг, букинг и т.п.
G>Что из этого не укладывается в сценарий: получить данные от биржи и выдать ордеры?
Получаем RFQ, прогоняем разные pre-trade проверки, check fail approvals, шлём запрос прайсерам, выбираем лучшую цену, запускаем проверки цены, публикуем цену, обрабатываем client counter, dealer counter, manual intervention, выполняем last-look, выполняем вычисление spot-цены, отсылаем heding, отсылаем booking.