У нас в компании те же задачи стоят, с разницей что не 3, а 2 веб-сервиса, написанных на разных языках и разных платформах.
Моё видение таково, что необходимо компонент за компонентом переводить на центральный веб-сервис JSON API, имеющий доступ к СУБД. API обязан иметь аутентикацию (
JSON Web Token или OAuth 2) и быть доступным только по HTTPS и
HSTS.
Всю предметную логику нужно иметь в одном месте для гарантии правильности работы и сокращения необходимых для разработки ресурсов.
Гарантию правильности даст покрытие тестами. Станет проще разрабатывать и не нужно будет разрываться на части. То есть двигаться можно в сторону расчленения на более мелкие сервисы. Будет проще разграничить зону ответственности каждому разработчику.
Если есть какие-то общие задачи, особенно долгоиграющие, то необходимо использовать очереди сообщений при помощи такого ПО как
Beanstalk, RabbitMQ или использовать
сторонние API. С помощью очередей можно добиться масштабируемости, отказоустойчивости и отвязаться от связанности сервисов и используемых технологий.
Быстрая скорость считывания данных
Она обеспечивается правильной архитектурой приложения и кешированием данных на API сервере, зная типичные сценарии использования. Тут могут подойти всякие решения типа memchached, Aerospike и т.д.
Согласен с
sim3x что WebSockets излишен для этих целей.