Суровая оптимизация работы с market data для криптобиржи

Про равенство тут можно спорить долго, но при количестве клиентов n, где n * ${время посылки данных} >= ${время посылки пакета по websocket} уже не подходит простая очередь, если говорить о равенстве строго.

Вполне допускаю, пока никто из мэйнстрима этим не озаботился, трейдеры будут кушать что дают.

С другой стороны на фоне интернета, это в принципе всё детский лепет, просто интересно, когда уже начнут появляться колокации и в этой области, кажется, что это вполне себе ожидаемый шаг в развитии.

Ещё маленькое замечание — у вас много ошибок в склонении существительных например:

о криптобиржи

По идее — спелчекер должен это решить.

1. В целом, я не против принят иную терминологию, нежели устоявшаяся в моем окружении. Это не меняет сути решения. Я даже рассматривал идею изменить статью для однозначного понимания того, что я продвигаю. Но не стал, по причине того, что кому бы я не показывал ее из своих знакомых, все прекрасно понимали о чем я написал. Хотя, после Вашего комментария, я еще раз обдумаю необходимость более полно раскрыть понятие «backend» в моем понимании;
2. Я уже задавал вопрос относительно того, что нет разницы между стеком с использованием прикладного кода + БД на backend (классика) и без него (предложенное решение). Прошу последовательно парировать приведенные в статье аргументы. Я ж старался, писал… А самый простой из них таков: любой backend это прикладное кастомизированные решение, в то время, как nginx это универсальный, надежный продукт известного, надежного вендора. В статье также приведены иные предпосылки для раскрытого решения. Странно, что люди с замахом на экспертное мнение, строят свою критику не на база последовательного опровержения приведенных в статье аргументов. Если собрать предпосылки в емкий второй вопрос, сформулирую его так — а какие требования к серверу, инфраструктуре и команде у решения со стеком, например PHP + MySQL + nginx, с учетом использования его в высоконагруженной системе? Наша нода фронта разворачивается на самой «дохлой» vps. Потому, что там кроме самого nginx нужен только linux. Мне кажется, разница очевидна.
3. Действительно, жаль, что люди не читают статью перед ее критикой. К моему большому сожалению, я отметил множество «грязных» комментариев, которые изобличают меня в поверхностном восприятии (к слову не тут, а там где мне даже шанс не предоставлен парировать) и т.д. Не удосужившись даже вникнуть в решение. Попытаться выразить его недостатки так как сделали это, например, Вы. А ведь это решение потребовало гораздо большего погружения в существующие технологии, чем «тупое копирование известных». Результат этой работы можно проверить, наглядно убедившись в реальности всех выводов. Просто возьмите для сравнения известную платформу TradingView и наш график. Посмотрите скорость работы того и другого при подгрузке данных.
4. Есть ли мысли как быстро вышла статья после внедрения этого решения? Решению уже год. Год. Я думаю, этот период можно считать достаточным, чтобы говорить, что оно проверено временем. Моя публикация вызвана не желанием стать известным или популярным. Я искренне верю, что криптобиржи с их парадигмой работы предоставления маркет-даты могут взять за основу это решение и получить массу профитов.
5. Изменение формата данных крайне маловероятно. Это устоявшийся формат. Именно это является коренной предпосылкой такого решения. Это красной нитью отражено в статье. Я не понимаю, почему в комментариях вновь и вновь люди возвращаются к этому вопросу. Но! Даже при его смене проблем нет. Как это не смешно, после предыдущего предложения, но мы формат меняли :) Правда по причине изменения разрядности полей. Почти уверен, что к удивлению для многих, в некоторых случаях, это проще чем с backend. Как так? Да очень просто. Когда вы меняете формат в backend может так статься, что отдаваемая структура несовместима в прошлой. А учитывая то, что мы используем еще и PWA технологию, наш фронт может быть закеширован на устройствах. И в случае такого изменения он просто будет падать намертво. Как решается вопрос с backend в этом случае? Самый простой способ, что я знаю, это версионирование API. Но… тогда мы раздуваем код и вынуждены увеличивать объем тестирования. А что же с файлами? Думаю, Вы уже поняли, что для этого достаточно просто «старые» файлики положить в папочку с прошлой версией и просто про них забыть. «Старые» версии фронта будут ходить к ним до обновления. Все. Неужели это не дает представление насколько экономится ресурс как в разработке, так и в продакшене?
6. Я не адепт ngnix. Я не адепт PHP, Java, Redis и т.п. Я считаю себя адептом разумного и релевантного решения. Внедряемые решения у нас на бирже проходят селекцию. Ни одно из них не внедряется просто потому, что кто-то имел положительную практику с ним или потому, что он «знает как нужно». Я например знаю MUMPS и считаю его лучшим, что произошло с миром :))
7. Corrupted… друзья, почему есть мнение, что этот сценарий нужно рассматривать как высокорисковый? Вероятность такого сценария низка. Почему? Я позволю тут переспросить вас — а какие причины могут быть к этому? И я готов каждую из них покрыть сценарием противодействия, которые у нас рассматриваются в рамках DRP стратегии.
8. Я готов спорить с решением, только, друзья, погрузитесь в тему криптобирж, их работы. Это не классические биржи. И нужно четко выделять понятие «торговый терминал» из всего трейдерского ассортимента продуктов. Именно для него, для этого частного решения и частного представления маркет-даты (график свечей) и релевантно данное решение
9. Как я уже сказал, я посмотрел на профиль umputun прежде чем писать свой ответ. У меня нет собственного мнения о его компетентности в вопросах классического фондового рынка. Я его не составил. Но те вопросы которые им поднимались, все же, имеют достаточно стандартные решения. И то, что их мне нужно объяснить… заставляет меня считать, что знаний именно в этой области, возможно, у него недостаточно. Ну невозможно знать все. Пожалуй, что интересно — а смотрел ли он на мой профиль? Все дело в том, что я конечно не в Чикаго, но создавал в свое время, если можно так назвать, ERP-систему для инвестиционной управляющей компании, входившей в TOP десятку по СЧА в России. В целом, мне кажется, мне известны все тяготы и лишения, с которыми он сталкивается. И создавая решения на проекте нашей биржи, я руководствуюсь полученным там опытом. Возможно, поверхностное восприятие статьи, пришедшей из «песочницы», сыграло плохую шутку.
10. Известным? У меня слишком много дел для того, чтобы быть известным:))) Я не против более детально раскрыть технологию, если это кому-то окажется интересным. Но мотиватор мой иной — желание создать что-то новое и интересное в мире криптобирж.