Future Features¶
Long-term ideas and improvements. These are not prioritized for current development but are worth revisiting as the product matures.
Team-level restore (and team-level checkpointing)¶
Current restore is all-or-nothing across all teams. Rolling back Team A also undoes Team B's recent work. The event-sourced architecture could support team-scoped restore (BuildDocumentAtSequence selectively restoring one team's subtree), but it would be a non-trivial extension. Team-level checkpointing could complement this.
Typed event system (reflection-based, open-closed processing)¶
The current event system uses stringly-typed EventType + Dictionary<string, string> data. A future improvement could introduce typed event classes (e.g., CreateTeamEvent, UpdatePrincipleTitleEvent) with a reflection-based dispatch registry. This would give compile-time safety for event data access, eliminate the TryGetValue/TryParse boilerplate in handlers, and make the EventTypes.All set self-maintaining via assembly scanning. The open-closed principle would allow adding new event types by just adding a class. Main obstacle: the checkpoint serialization format and cold start replay would need migration support.
Data retention policy and cleanup¶
The checkpoints and events tables will accumulate indefinitely. At scale, a retention policy should address:
- Pruning old checkpoints (only the most recent N or those within a time window are needed for cold start)
- Archiving or compacting old event log entries beyond a certain age
- Defining retention windows appropriate to operational and audit needs
Not relevant for 3-5 years given expected usage, but should be revisited as data volumes grow.