Los planos de Styx, la regla Bun decide y Zig ejecuta, los servicios y cómo está construido cada uno por dentro.
Implementado. Describe la topología que existe en el repositorio. La referencia de cada servicio (rutas HTTP, subjects del bus, variables de entorno) se genera del código bajo
referencia/y no se repite aquí.
Styx separa por diseño lo que decide de lo que ejecuta. Los cinco planos vienen del diseño original (decisión r02, origen en el brainstorm de arquitectura) y siguen vigentes:
CLIENTES web · apps nativas · CLI · agentes
│
DELIVERY HLS · HTTP Range · HTTP/3 · WebTransport · MoQT
│
DATA PLANE styx-media-daemon (Zig): E/S, caché, índices, motor de medios, sesiones, transportes
│ socket de control (spire)
CONTROL PLANE servicios Bun/Elysia: API, identidad, catálogo, planes, políticas, extensiones
│
PERSISTENCIA PostgreSQL · Valkey · NATS JetStream · raíces de ficheros del daemonDos reglas gobiernan la frontera entre el control plane y el data plane:
dec-0012, dec-0014). El control plane expresa intención y
política (qué plan de reproducción, quién puede leer qué). El daemon posee el camino completo
desde esa intención hasta el byte entregado por QUIC.El orden de preferencia de la frontera Bun↔Zig es: daemon sobre socket Unix, después Node-API,
después bun:ffi. Esta última nunca es la frontera principal.
Un contenedor por responsabilidad (dec-0002, dec-0003), sin modo monolito. Que un servicio
esté implementado o sea un esqueleto se mira en apps/, no en esta tabla, que sólo dice qué hace
cada uno:
| Pieza | Responsabilidad |
|---|---|
identity-svc | Relying party OIDC (Pocket ID de referencia), emisor de tokens de acceso, dueño de actores y sesiones, JWKS |
catalog-svc | Catálogo federado (obra, edición, asset, índice de medios) y alta de ficheros ingeridos |
playback-svc | Planificación de reproducción, sesiones contra el daemon, emisión de capacidades (SCT) y decisión de quién puede subir |
sources-svc | Registro de fuentes, disponibilidad y selección de la fuente de un asset |
realtime-svc | Proyección de señales de transporte filtradas hacia los clientes por WebSocket |
workers-svc | Contenedor de la topología; hoy sólo sirve /health (el probe con ffprobe se retiró por dec-0110) |
extensions-svc | Autoridad de manifests y ciclo de vida de extensiones; sin código todavía |
styx-media-daemon | Data plane en Zig: motores de medios, caché, transportes, ingesta, relay MoQT |
apps/web | Web (TanStack Start). Hace de BFF: es el único origen de control plane que ve el navegador (dec-0118) |
Ningún servicio importa a otro: se hablan por el bus (cmd, qry, evt) o por el socket de
control del daemon. La única excepción documentada es el tipo (sólo tipo) de la aplicación de
catalog-svc que consume @styx/clients para el cliente Eden.
Cada servicio Elysia sigue cinco capas y no crea una capa sin una responsabilidad real:
src/
├── core/{handlers,ports}/ lógica pura y puertos (interfaces)
├── service/<adaptador>/ implementación de los puertos: base de datos, bus, OTel, daemon
├── transport/http/routes/ rutas Elysia 2 con los contratos TypeBox de @styx/api-contracts
├── bootstrap.ts cableado, listeners y apagado ordenado
├── app.aot.ts la misma aplicación para la captura del bundle AOT
└── test/ core, service, transport, integration, smokeLos servicios se empaquetan como un bundle AOT (dist/bootstrap.js) que sirve la imagen de
docker/<servicio>.Dockerfile (dec-0116). La base HTTP común está en @styx/service-http:
problemas RFC 9457, política deny-by-default por ruta, cabeceras y verificación de rutas.
apps puede depender de packages; packages no depende de apps (excepción de arriba).packages, la dirección sana es del consumidor al contrato: playback-policy
depende de api-contracts, nunca al revés.@styx/api-contracts es la fuente canónica de los contratos y no importa elysia: a Elysia se
le pasa el esquema crudo (bus y contratos).