Arquitectura de backend distribuido de la aplicación de Stock.
Información general
Estoy construyendo una aplicación de stock como un proyecto secundario y esta es la arquitectura actual que estoy usando:
- Frontend de React con la biblioteca de sockets @microsoft/signalr
- Backend de ASP.NET Core con SignalR Hub para manejar los sockets del cliente
- API REST de Polygon.io como fuente de datos financieros
- Redis para almacenar las cotizaciones de acciones para que varios nodos de API puedan consultar los datos
Aquí hay un ejemplo de la arquitectura preliminar que he ideado:
Algunos desafíos
– Las cotizaciones de las acciones deben actualizarse cada segundo/cada pocos segundos para una buena experiencia de usuario
– Varios clientes comparten suscripciones a las mismas acciones
– Solo en la NYSE hay n=11,750
acciones posibles a las que suscribirse
El mecanismo de actualización actual
Cliente 1
- Cliente #1 se conecta a Nodo de API #1
- Cliente #1 se suscribe a
$AAPL
,$TSLA
- Nodo de API #1 inicia un temporizador, cada 2 segundos obtiene datos de Redis y busca las claves
AAPL
yTSLA
para ver si existen valores, si faltan valores, obtiene los datos faltantes de Polygon, luego los almacena en Redis y almacena en caché las claves durante 3 segundos. - Se devuelve la mezcla de datos en caché/nuevos a Cliente #1
Cliente 2
- Cliente #2 se conecta a Nodo de API #2
- Cliente #2 se suscribe a
$AAPL
,$TSLA
,$GOOG
,$AMZN
- Comparte las suscripciones de
$AAPL
y$TSLA
con Cliente #1 - Nodo de API #2 inicia un temporizador, cada 2 segundos obtiene datos de Redis y busca las claves
AAPL
,TSLA
,GOOG
,AMZN
para ver si existen valores, si faltan valores, obtiene los datos faltantes de Polygon, luego los almacena en Redis y almacena en caché las claves durante 3 segundos. - Se devuelve la mezcla de datos en caché/nuevos a Cliente #2
El problema
Cliente #1 y Cliente #2 comparten suscripciones y a veces intentarán actualizar las mismas claves en Redis y obtener datos de Polygon para las mismas acciones. ¿Cuál sería la forma más eficiente para que los nodos de API actualicen las acciones?
Soluciones para una escalabilidad eficiente
¿Debería crear un trabajador central que consulte a Polygon.io y actualice TODAS las suscripciones agregadas de acciones en Redis, y los nodos de API solo obtengan datos de la caché de Redis?
davy.ai
Solución: Trabajador Centralizado de Actualización de Stock
Para escalar eficientemente el proceso de actualización de stock y evitar conflictos entre los nodos de la API, se puede implementar un trabajador centralizado para consultar a Polygon.io y actualizar todas las suscripciones de stock agregadas en Redis. Este trabajador se encargaría de actualizar los datos para todos los clientes, eliminando la necesidad de que varios nodos de API consulten independientemente a Polygon.io y almacenen los datos en Redis. En cambio, los nodos de la API simplemente pueden consultar la caché de Redis para obtener la información más reciente de stock.
Ventajas del Trabajador Centralizado de Actualización de Stock
Consideraciones para el Trabajador Centralizado de Actualización de Stock
En general, implementar un trabajador centralizado de actualización de stock sería una solución escalable y eficiente para manejar las actualizaciones de stock en un entorno de múltiples clientes.