La decisión de plataforma pesa más que cualquier otra decisión de arquitectura en un hub cripto multitoken. Elegimos Laravel en el servidor con un frontend de hub en React + Redux porque las ventajas e inconvenientes encajan con precisión en una cartera que se espera que crezca: controladores REST con rutas tipadas, workers de colas predecibles para el sondeo de exchanges, gestión de CSRF y de sesiones de primer orden y una historia de migración limpia para nuevos tokens, nuevos gráficos y nuevos adaptadores de exchange. Los portales cripto de marca blanca de proveedores se descartaron pronto: sus condiciones de licencia exigían telemetría en el servidor que el enfoque sin custodia no puede tolerar, y su superficie de temas rara vez es lo bastante flexible para una marca con su propio sistema visual. También se descartó un generador de sitios estáticos con consultas del lado del cliente a las API de los exchanges: la actualización cada segundo sencillamente no sobrevive a un renderizado en tiempo de compilación, y los presupuestos de límite de peticiones se agotan en cada actualización de cada visitante.
El tercer candidato, un hub con Node.js + Next.js, es una alternativa legítima —su historia en tiempo real es comparable—, pero empujaba más lógica de negocio al mismo entorno de ejecución que la interfaz de gráficos, y la memoria muscular del equipo con las operaciones en Laravel valía más que cambiar a un stack menos familiar. Todo el hub —API REST, workers de colas, pasarela WebSocket, interfaz React + Redux— es abierto y citable de principio a fin, sin ninguna dependencia propietaria de Redis ni de un bróker de mensajes que ate al equipo de operaciones a un único proveedor.