Arquitectura

DuneStack sigue una arquitectura de cluster descentralizada donde cada nodo ejecuta los mismos binarios pero asume roles diferentes según el consenso Raft. No existe un "control plane" separado — todos los nodos son iguales y el liderazgo se elije dinámicamente.

Topología del cluster

Un cluster DuneStack mínimo requiere 3 nodos para tolerancia a fallas. Cada nodo ejecuta:

• ✦Spice — participa en Raft consensus (1 líder, N-1 followers)
• ✦Fremen — agente local que reporta métricas y ejecuta workloads
• ✦Spacing Guild — instancia del gateway (load balanced entre nodos)
• ✦Sandworm — scheduler (solo activo en el nodo líder)
• ✦Sietch — store analítico (réplica en cada nodo)

Flujo de datos

Puertos

Consenso Raft

Spice implementa Raft consensus para mantener el estado del cluster replicado en todos los nodos. El líder procesa todas las escrituras y las replica a los followers. Si el líder cae, se elije uno nuevo automáticamente en < 500ms.

• ✦Elección de líder automática con timeout configurable
• ✦Log replication con batching para throughput máximo
• ✦Snapshots incrementales cada 10,000 entradas
• ✦Tolerancia: un cluster de N nodos soporta (N-1)/2 fallas
• ✦3 nodos → 1 falla tolerada, 5 nodos → 2 fallas toleradas

Flujo de un request

Todo request externo entra por Spacing Guild (único punto de entrada público). El gateway resuelve el servicio destino consultando el estado en Spice, aplica rate limiting y circuit breakers, y rutea al nodo correspondiente.

• ✦Cliente envía request a Spacing Guild (:8080)
• ✦Gateway consulta Spice para resolver el servicio (in-memory, ~0.1ms)
• ✦Rate limit check contra el estado distribuido
• ✦Forward al servicio destino en el nodo correspondiente
• ✦Response al cliente — latencia total overhead: ~0.3ms