Заключение

1. Приём данных: Data Receiver получает поток с биржи.
2. Хранение и публикация: Данные записываются в Redis, который публикует обновления.
3. Подписка клиентов: API серверы подписываются на нужные каналы Redis в зависимости от подписок клиентов.
4. Доставка клиентам: API серверы сразу передают обновления клиентам через gRPC стримы (или WebSocket)
5. Синхронизация: При подключении клиента ему сначала отправляется актуальный снимок данных из Redis, затем начинаются стриминговые обновления.

Архитектура реализует паттерн fan-out:

• Один источник данных (биржа)
• Несколько Data Receiver’ов
• Несколько реплик Redis
• Множество стриминговых API серверов
• Миллионы клиентов

Так обеспечивается масштабируемость и низкая задержка доставки.

• Репликация Redis для сохранности данных + backup система
• Множество API серверов для отказоустойчивости клиентских подключений
• Снимки (snapshot) Redis для восстановления после сбоев
• Кластер LB для отказоустойчивости балансировки

Проблемы Redis и как их можно решить с Dragonfly: https://www.dragonflydb.io/blog/redis-scaling-mistakes