trm/processor
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: update task 1.5.2 done section and ROADMAP status

Browse Source
This commit is contained in:
Julian Çuni
2026-05-02 17:36:43 +02:00
parent 20ebd9b473
commit 7450cbffaa
8 changed files with 1076 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.planning/phase-4-future/README.md
+1 -1
View File
@@ -14,7 +14,7 @@ Ideas on radar that may or may not become real tasks. Captured here so they don'
- **Alternate consumer for analytics export.** A second consumer group reading the same stream, writing to a parallel destination (Parquet on object storage, ClickHouse, etc.) for offline analytics. The Phase 1 architecture already supports this — it's a separate process joining the same stream with a different group name. No Processor changes needed; just operational scaffolding.
- **WebSocket gateway for live updates.** If Directus's WebSocket subscriptions hit a fan-out ceiling for spectator-facing live leaderboards, a dedicated gateway reads from Redis and pushes to clients, bypassing Directus for the live channel only. REST/GraphQL stays in Directus. Mentioned in `wiki/entities/directus.md`.
- **Lifting the live-broadcast WebSocket out of the Processor into a standalone gateway service.** Phase 1.5 implements the WS endpoint inside the Processor process per [[live-channel-architecture]]. If sustained throughput exceeds the threshold documented there (~10k WS messages/sec, or connection-time auth becomes a thundering herd at race start with thousands of viewers), the wiki's documented escape hatch is to extract the WS code into a standalone service that subscribes to the same `live-broadcast-*` consumer group. The Redis-stream-in / WebSocket-out contract doesn't change; only the host process does. Promote this to a numbered phase only when measurements justify it.
- **Per-instance sharding hint.** If consumer-group load distribution turns out to be uneven (one instance handles all the chatty devices), introduce hashing-by-device-id with explicit assignment. Probably overkill — Redis Streams' default round-robin works for most workloads.