6c:T41a,Consider a bank account with a balance of $1,000. In traditional systems, that $1,000 is simply a number stored in a database column. But this single number hides an entire history: the initial deposit, salary payments, ATM withdrawals, online purchases, interest accruals, and fee deductions that together produced that balance. **When we store only current state, we lose the story of how we arrived there.** This loss has profound consequences. When a customer disputes a transaction, we scramble through fragmented logs. When auditors ask "what did this account look like on March 15th?", we cannot answer with certainty. When a bug corrupts balances, we have no definitive record to restore from. When regulations require us to prove *why* a system made a decision, we find ourselves unable to explain. Event sourcing inverts this model entirely. Instead of storing the answer (current state), we store the complete derivation (all events). The answer becomes a function of that derivation—reproducible, auditable, and temporally queryable.6d:T701,// Domain events are immutable facts about what happened interface DomainEvent { // Unique identifier for this specific event instance readonly eventId: string; // Type of event (discriminator for deserialization) readonly eventType: string; // Aggregate this event belongs to readonly aggregateId: string; readonly aggregateType: string; // Position in the aggregate's event stream readonly sequenceNumber: number; // When the event occurred readonly timestamp: Date; // The actual event data (varies by event type) readonly payload: Record; // Optional metadata (causation, correlation, user, etc.) readonly metadata?: EventMetadata; } // Concrete event examples interface AccountOpened extends DomainEvent { readonly eventType: 'AccountOpened'; readonly payload: { accountNumber: string; customerId: string; accountType: 'checking' | 'savings'; initialDeposit: number; currency: string; }; } interface FundsDeposited extends DomainEvent { readonly eventType: 'FundsDeposited'; readonly payload: { amount: number; currency: string; depositMethod: 'cash' | 'wire' | 'check' | 'transfer'; reference: string; }; } interface FundsWithdrawn extends DomainEvent { readonly eventType: 'FundsWithdrawn'; readonly payload: { amount: number; currency: string; withdrawalMethod: 'atm' | 'wire' | 'check'; atmId?: string; reference: string; }; } // Event metadata for traceability interface EventMetadata { causationId: string; // Event that caused this event correlationId: string; // Business transaction ID userId?: string; // Who initiated the action userAgent?: string; // Client information ipAddress?: string; // Request origin }6e:Tb97,// Current state is derived by applying all events in sequence interface BankAccountState { accountId: string; customerId: string; balance: number; accountType: 'checking' | 'savings'; status: 'active' | 'frozen' | 'closed'; lastActivity: Date; } // The fold/reduce operation that derives state from events function deriveAccountState(events: BankAccountEvent[]): BankAccountState | null { return events.reduce((state, event) => { switch (event.eventType) { case 'AccountOpened': // Handle initial event—creates the aggregate return { accountId: event.aggregateId, customerId: event.payload.customerId, balance: event.payload.initialDeposit, accountType: event.payload.accountType, status: 'active', lastActivity: event.timestamp, }; case 'FundsDeposited': if (!state) throw new Error('Cannot deposit to non-existent account'); return { ...state, balance: state.balance + event.payload.amount, lastActivity: event.timestamp, }; case 'FundsWithdrawn': if (!state) throw new Error('Cannot withdraw from non-existent account'); return { ...state, balance: state.balance - event.payload.amount, lastActivity: event.timestamp, }; case 'AccountFrozen': if (!state) throw new Error('Cannot freeze non-existent account'); return { ...state, status: 'frozen', lastActivity: event.timestamp, }; case 'AccountClosed': if (!state) throw new Error('Cannot close non-existent account'); return { ...state, status: 'closed', balance: 0, // Assuming closure requires zero balance lastActivity: event.timestamp, }; default: // Unknown event type—log warning but don't fail console.warn(`Unknown event type: ${(event as any).eventType}`); return state; } }, null); } // Temporal query: "What was the balance on March 15, 2024?" function getStateAtTime( events: BankAccountEvent[], asOf: Date ): BankAccountState | null { const eventsUpToDate = events.filter(e => e.timestamp <= asOf); return deriveAccountState(eventsUpToDate); } // Example usage const events: BankAccountEvent[] = [ { eventType: 'AccountOpened', timestamp: new Date('2024-01-01'), /* ... */ }, { eventType: 'FundsDeposited', timestamp: new Date('2024-01-15'), /* ... */ }, { eventType: 'FundsWithdrawn', timestamp: new Date('2024-02-01'), /* ... */ }, { eventType: 'FundsDeposited', timestamp: new Date('2024-03-01'), /* ... */ }, ]; // Current state: replay all events const currentState = deriveAccountState(events); // Historical state: what was the balance on Feb 15? const feb15State = getStateAtTime(events, new Date('2024-02-15'));6f:T421,The immutability of events is not merely a technical constraint—it is the foundational property that enables every benefit event sourcing provides. Understanding why immutability matters, and how to maintain it, is essential. **Why Events Must Be Immutable** 1. **Trustworthy Audit Trail**: Auditors, regulators, and dispute resolution processes require confidence that records weren't altered after the fact. Immutable events provide cryptographic-level assurance that what you see is what happened. 2. **Reproducibility**: If events could change, replaying the event stream could yield different states depending on when you replayed. Immutability guarantees that state reconstruction is deterministic. 3. **Safe Distribution**: Events can be safely replicated to other systems, cached, and archived because they won't change. Downstream systems don't need to poll for corrections. 4. **Debugging Time Travel**: When investigating production issues, you can replay events to reproduce exact historical states. Mutability would make this unreliable.70:T6f1,// Scenario: Customer was charged incorrectly // Wrong approach: Update or delete the original event (NEVER DO THIS) // Correct approach: Add compensating events // Original event that contained an error const incorrectCharge: PaymentEvent = { eventId: 'evt-001', eventType: 'PaymentCharged', aggregateId: 'cust-123', sequenceNumber: 15, timestamp: new Date('2024-03-10T14:30:00Z'), payload: { amount: 999.99, // Error: should have been 99.99 currency: 'USD', description: 'Monthly subscription', }, }; // Compensating event that logically reverses the mistake const refund: PaymentEvent = { eventId: 'evt-002', eventType: 'PaymentRefunded', aggregateId: 'cust-123', sequenceNumber: 16, timestamp: new Date('2024-03-11T09:00:00Z'), payload: { originalEventId: 'evt-001', refundAmount: 999.99, reason: 'Incorrect charge amount - should have been 99.99', initiatedBy: 'support-agent-456', }, metadata: { causationId: 'evt-001', correlationId: 'support-ticket-789', }, }; // Corrected charge event const correctCharge: PaymentEvent = { eventId: 'evt-003', eventType: 'PaymentCharged', aggregateId: 'cust-123', sequenceNumber: 17, timestamp: new Date('2024-03-11T09:01:00Z'), payload: { amount: 99.99, // Correct amount currency: 'USD', description: 'Monthly subscription (corrected)', relatedRefund: 'evt-002', }, metadata: { correlationId: 'support-ticket-789', }, }; // The event stream now tells the COMPLETE story: // 1. We charged $999.99 (mistakenly) // 2. We refunded $999.99 (acknowledging the error) // 3. We charged $99.99 (correctly) // // An auditor can see exactly what happened. // Replaying produces correct current state. // No information was destroyed.71:Tc3f,interface TemporalQueryService { // Get state at a specific point in time getStateAt( aggregateId: string, timestamp: Date, reducer: (events: DomainEvent[]) => T ): Promise; // Get all states at regular intervals (for trend analysis) getStateOverTime( aggregateId: string, startDate: Date, endDate: Date, interval: Duration, reducer: (events: DomainEvent[]) => T ): Promise>; // Compare state between two points getStateDiff( aggregateId: string, t1: Date, t2: Date, reducer: (events: DomainEvent[]) => T, differ: (s1: T, s2: T) => StateDiff ): Promise; } class EventStoreTemporalQueries implements TemporalQueryService { constructor(private eventStore: EventStore) {} async getStateAt( aggregateId: string, timestamp: Date, reducer: (events: DomainEvent[]) => T ): Promise { // Find the most recent snapshot before the target time const snapshot = await this.eventStore.getLatestSnapshotBefore( aggregateId, timestamp ); // Get events from snapshot (or beginning) to target time const events = await this.eventStore.getEvents({ aggregateId, fromSequence: snapshot?.sequenceNumber ?? 0, toTimestamp: timestamp, }); // If we have a snapshot, start from that state if (snapshot) { const newEvents = events.filter( e => e.sequenceNumber > snapshot.sequenceNumber ); return this.applyEventsToState(snapshot.state, newEvents, reducer); } // Otherwise replay from beginning return reducer(events); } async getStateOverTime( aggregateId: string, startDate: Date, endDate: Date, interval: Duration, reducer: (events: DomainEvent[]) => T ): Promise> { const results: Array<{ timestamp: Date; state: T }> = []; // Get all events in the time range once const allEvents = await this.eventStore.getEvents({ aggregateId, fromTimestamp: new Date(0), // From beginning toTimestamp: endDate, }); // Replay incrementally at each interval let currentTime = startDate; while (currentTime <= endDate) { const eventsUpToNow = allEvents.filter(e => e.timestamp <= currentTime); const state = reducer(eventsUpToNow); results.push({ timestamp: new Date(currentTime), state }); currentTime = addDuration(currentTime, interval); } return results; } // Example: Analyze how account balance changed over time async analyzeBalanceHistory(accountId: string): Promise { const history = await this.getStateOverTime( accountId, new Date('2024-01-01'), new Date('2024-12-31'), { days: 1 }, // Daily snapshots events => deriveAccountState(events)?.balance ?? 0 ); return { dataPoints: history, min: Math.min(...history.map(h => h.state)), max: Math.max(...history.map(h => h.state)), average: history.reduce((sum, h) => sum + h.state, 0) / history.length, }; } }64:{"json":{"id":"seed_99d1553a4e7256192a89dabc538e32bd","slug":"hld-distributed-data-patterns-event-sourcing","category":"System Design (HLD)","topic":"Event Sourcing","title":"Event Sourcing: Events as the Source of Truth","description":"Master the event sourcing pattern for distributed systems. Learn how storing immutable events instead of mutable state enables complete audit trails, temporal queries, system debugging, and powerful integration capabilities that traditional CRUD cannot achieve.","difficulty":"ADVANCED","estimatedMinutes":75,"pages":[{"id":"seed_676daed15c3e303a1b592e5001dbe628","title":"Events as Source of Truth","order":0,"content":[{"id":"opening-hook","title":"The Problem with State","content":[{"data":{"content":"$6c"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the fundamental paradigm shift event sourcing represents, why events constitute a more powerful primary record than state, the immutability guarantees that make event sourcing trustworthy, and how this pattern changes the way we design distributed systems. You'll see why industry leaders like LinkedIn, Netflix, and financial institutions have adopted event sourcing for their most critical systems.","variant":"info"},"type":"callout"}]},{"id":"state-persistence-paradigm","title":"The State Persistence Paradigm","content":[{"data":{"content":"For decades, the dominant model for data persistence has been **CRUD** (Create, Read, Update, Delete). In this paradigm, we model our domain as entities with attributes, store the current values of those attributes in database rows, and modify those values as the system evolves. The database serves as the authoritative record of \"what is true right now.\"\n\nThis approach has obvious appeal:\n\n- **Simplicity**: Querying current state is a direct database read\n- **Efficiency**: Storage requirements correlate with entity count, not operation count\n- **Familiarity**: SQL databases, ORMs, and most frameworks assume this model\n\nHowever, CRUD carries fundamental limitations that become critical in complex, distributed, or regulated systems."},"type":"text"},{"data":{"rows":[["Information Destruction","Updates overwrite previous values; delete removes records entirely","Historical analysis impossible; compliance failures; dispute resolution blocked"],["Temporal Blindness","Cannot query 'what was the state on date X' without additional infrastructure","Audits require custom solutions; debugging race conditions extremely difficult"],["Intent Opacity","State captures 'what' but not 'why' or 'how'","System behavior cannot be explained; root cause analysis complicated"],["Integration Brittleness","Other systems must poll for changes or rely on fragile triggers","Tight coupling; missed events; synchronization failures"],["Recovery Complexity","Corruption requires either backup restoration or manual reconstruction","Data loss risk; extended downtime; inconsistent recovery states"]],"caption":"Inherent Limitations of State-Based Persistence","headers":["Limitation","Description","Business Impact"]},"type":"table"},{"data":{"content":"**The Update Problem in Detail**\n\nConsider a user profile system. When a user changes their email address:\n\n```sql\nUPDATE users SET email = 'new@example.com' WHERE id = 42;\n```\n\nThis single statement destroys information. The previous email? Gone. When was it changed? Unknown (unless we added separate audit logging). Who changed it? The application, but which code path? If this update was part of a larger operation that partially failed, can we identify which changes completed? In a CRUD system, answering these questions requires additional infrastructure layered on top—audit tables, change data capture, application-level logging. But these are band-aids over a fundamental architectural limitation.\n\n**State is a lossy compression of history.** We've traded information for storage efficiency—a tradeoff that was reasonable when storage was expensive and analytical requirements were simpler, but increasingly problematic in modern systems."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Illusion of Simplicity","content":"CRUD appears simpler only when requirements are limited to 'show me the current state.' The moment you need history, audit trails, debugging capabilities, or event-driven integrations, CRUD becomes complex—requiring separate logging systems, change tracking tables, triggers, and reconciliation processes that often become more complex than event sourcing itself.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"events-first-class-citizens","title":"Events as First-Class Citizens","content":[{"data":{"content":"Event sourcing inverts the traditional model. Instead of storing current state and deriving events (through logging, CDC, or triggers), we store events and derive current state. **Events become the source of truth; state becomes a read optimization.**\n\nAn **event** is an immutable record of something that happened—a fact about the past that cannot be changed. Events are named in the past tense because they represent completed actions:\n\n- `AccountOpened` (not `OpenAccount`)\n- `FundsDeposited` (not `DepositFunds`)\n- `OrderShipped` (not `ShipOrder`)\n- `EmailAddressChanged` (not `ChangeEmailAddress`)\n\nThis distinction matters. Commands represent intentions that might fail; events represent facts that have already occurred. Events are never rejected, updated, or deleted—they simply *are*."},"type":"text"},{"data":{"fileName":"event-structure.ts","languages":[{"code":"$6d","label":"TypeScript","value":"typescript"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Event Characteristics**\n\nWell-designed events share several critical properties:\n\n1. **Immutability**: Once recorded, events never change. This is fundamental—if events could be modified, we'd lose the trustworthy audit trail that makes event sourcing valuable.\n\n2. **Self-Describing**: Events contain all information needed to understand what happened without external context. An event retrieved years later should be interpretable.\n\n3. **Ordered**: Events within an aggregate (a consistency boundary) have a strict total order given by sequence numbers. This ordering is essential for correct state reconstruction.\n\n4. **Complete**: The event stream contains every fact needed to reconstruct current state. Nothing relevant happens \"off the books.\"\n\n5. **Business-Meaningful**: Events represent domain concepts, not technical operations. `CustomerUpgradedToGold` is superior to `CustomerTableRowUpdated`."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Events vs. Event Notifications","content":"Event sourcing events are rich, containing all relevant data. Event notifications (used in pub/sub messaging) can be thin, containing just identifiers and type. Don't conflate these patterns. In event sourcing, the event IS the data. In event notification, the event announces that data exists elsewhere.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"fundamental-inversion","title":"The Fundamental Inversion","content":[{"data":{"content":"The paradigm shift from state-first to event-first thinking is profound. Let's visualize this inversion to understand what changes and what remains constant."},"type":"text"},{"data":{"left":[{"data":{"items":["**Primary Store**: Current state in relational tables","**Writes**: UPDATE statements that overwrite values","**History**: Optional; via audit logs or CDC","**Temporal Query**: Requires bitemporal schema design","**Truth**: What the database says *now*","**Integration**: Poll for changes or fragile triggers","**Recovery**: Restore from backup; pray for consistency"],"title":{"icon":"XCircle","text":"State-First (Traditional CRUD)","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Primary Store**: Append-only event log","**Writes**: INSERT of immutable events only","**History**: Intrinsic; the event stream IS history","**Temporal Query**: Replay events to any point in time","**Truth**: What happened, in what order","**Integration**: Subscribe to event stream","**Recovery**: Replay from known-good snapshot or beginning"],"title":{"icon":"CheckCircle","text":"Event-First (Event Sourcing)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**The Mathematical Analogy**\n\nConsider the relationship between a function and its integral:\n\n- In calculus, the integral ∫f(x)dx gives you accumulated change\n- The current value at point T is the sum of all changes from 0 to T\n- The derivative f(x) = dF/dx recovers the rate of change at any point\n\nEvent sourcing applies this principle to data:\n\n- Events are the \"infinitesimal changes\"\n- Current state is the \"integral\"—the sum of all events\n- Any historical state can be computed by integrating only up to that point\n\nJust as integration can be computed from any starting point with known initial conditions, current state can be rebuilt from events starting from any snapshot."},"type":"text"},{"data":{"fileName":"state-derivation.ts","languages":[{"code":"$6e","label":"TypeScript","value":"typescript"}],"showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":3},{"id":"immutability-foundation","title":"Immutability as Foundation","content":[{"data":{"content":"$6f"},"type":"text"},{"data":{"items":["**Corrections**: Add a compensating event (e.g., `PaymentRefunded` instead of deleting `PaymentReceived`). The original event remains as historical fact; the correction is a new fact that affects derived state.","**Mistakes**: Add an explicit `EventCorrection` or domain-specific correction event (e.g., `IncorrectChargeReversed`). Include reference to the original event and explanation.","**Regulatory Requirements**: For GDPR erasure, consider event replacement with crypto-shredding—encrypt sensitive data per user, then delete encryption keys. The event structure remains; the data becomes unreadable.","**Schema Evolution**: Events are written with a version. Readers handle multiple versions through upcasting (transforming old versions to new on read) rather than modifying stored events."],"title":{"icon":"AlertCircle","text":"Handling \"Changes\" Without Mutation","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Temptation to Mutate","content":"Under pressure to 'fix' bad data quickly, teams sometimes corrupt their event store with direct modifications. Resist this urge absolutely. Once you modify events, you've lost the core value proposition. Every system that depends on event immutability—auditing, replay, debugging, projections—becomes unreliable. Use compensating events instead; they're more work upfront but preserve system integrity.","variant":"warning"},"type":"callout"},{"data":{"fileName":"compensating-events.ts","languages":[{"code":"$70","label":"TypeScript","value":"typescript"}],"showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":4},{"id":"transactions-to-time-travel","title":"From Transactions to Time Travel","content":[{"data":{"content":"One of event sourcing's most powerful capabilities is **temporal querying**—the ability to answer questions about the past or to reconstruct the system's state at any historical point. This capability emerges naturally from the append-only event model.\n\n**Use Cases for Temporal Queries**\n\n- **Auditing**: \"Show me exactly what this account looked like when the suspicious transaction occurred\"\n- **Debugging**: \"What was the system state that led to this bug being triggered?\"\n- **Analytics**: \"How has customer behavior evolved over the past quarter?\"\n- **Legal Discovery**: \"Produce the exact record state as of the contract signing date\"\n- **What-If Analysis**: \"If we had implemented this business rule in January, how would outcomes differ?\""},"type":"text"},{"data":{"rows":[["Point-in-Time State","Replay events up to target timestamp","Keep periodic snapshots to avoid full replay"],["State Difference","Reply to T1, then to T2; diff the states","Useful for understanding what changed"],["Event Slice","Filter events by time range and/or type","Direct query against event store"],["Trend Analysis","Replay at regular intervals, aggregate states","Materialized views can optimize this"],["Counterfactual","Replay with modified events or rules","Requires isolated replay environment"]],"caption":"Temporal Query Patterns","headers":["Query Pattern","Implementation","Performance Consideration"]},"type":"table"},{"data":{"fileName":"temporal-queries.ts","languages":[{"code":"$71","label":"TypeScript","value":"typescript"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"The Debugging Superpower","content":"When production bugs occur, event sourcing lets you replay the exact sequence of events that led to the error. This is dramatically more powerful than log analysis because you can literally reproduce the system state, step through the event application, and observe exactly where things went wrong. Combined with event replay in a development environment, this capability can reduce debugging time from days to hours.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"distributed-systems-context","title":"Event Sourcing in Distributed Systems","content":[{"data":{"content":"Event sourcing provides unique advantages in distributed system architectures. The append-only nature of events, combined with their immutability, solves several classic distributed systems problems.\n\n**Natural Integration Pattern**\n\nIn traditional systems, integrating with downstream systems requires either:\n- Polling for changes (inefficient, latent, doesn't scale)\n- Database triggers (fragile, tightly coupled)\n- Application-level publishing (dual writes, consistency issues)\n\nWith event sourcing, the event stream itself becomes the integration point. Downstream systems subscribe to events, consuming the same immutable record that the originating system uses. This is not a secondary log or a derived feed—it's the actual source of truth."},"type":"text"},{"data":{"items":["**Decoupling**: Producers and consumers don't need to know about each other. The event stream is the contract.","**Resilience**: If a consumer fails, it can restart from its last known position. Events aren't lost; they're durable.","**Scalability**: Multiple consumers can read the same events independently. No coordination required.","**Consistency**: All consumers see the same events in the same order. No synchronization divergence.","**New Consumer Bootstrapping**: A new service can build its state by replaying all historical events—instant catch-up."],"title":{"icon":"Zap","text":"Distributed System Benefits","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Event Sourcing vs. Event-Driven Architecture**\n\nThese terms are often conflated but represent distinct concepts:\n\n**Event-Driven Architecture (EDA)** is about communication patterns—systems notifying each other through events rather than direct calls. The events might be transient, stored temporarily in message brokers.\n\n**Event Sourcing** is about data persistence—using events as the authoritative record of state. Events must be stored permanently and are the source of truth.\n\nYou can have EDA without event sourcing (using traditional databases but communicating via messages). You can have event sourcing without full EDA (using events for persistence but still making synchronous calls between services). The combination of both creates particularly powerful architectures, but understanding the distinction is important for design decisions."},"type":"text"},{"data":{"icon":"Info","title":"Industry Adoption","content":"Event sourcing is not academic theory—it's production reality at massive scale. LinkedIn's Kafka platform is fundamentally an event sourcing infrastructure. Netflix uses event sourcing for many critical services. Financial institutions use it for trade capture and regulatory reporting. The pattern has been battle-tested at scales measured in millions of events per second.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"natural-model","title":"When Events Are the Natural Model","content":[{"data":{"content":"Some domains are naturally event-oriented—the real-world processes they model are sequences of things that happen, not static states that get updated. In these domains, event sourcing isn't an architectural choice; it's a recognition of how the domain actually works.\n\n**Naturally Event-Oriented Domains**"},"type":"text"},{"data":{"rows":[["Financial Services","Transactions, transfers, trades, payments","A ledger is literally a sequence of entries. Summarizing to a 'balance' loses critical information."],["Healthcare","Prescriptions, diagnoses, treatments, vitals","Medical history matters as much as current state. Changes must be explained."],["Supply Chain","Orders, shipments, customs, deliveries","Tracking requires knowing what happened at each step, not just current location."],["Legal/Contracts","Agreements, amendments, signatures, disputes","The sequence of legal actions is the record. You can't 'update' a signed contract."],["Gaming","Actions, achievements, purchases, level-ups","Player history enables analytics, fairness checks, and replay features."],["IoT/Sensors","Readings, alerts, calibrations, maintenance","Sensor data is inherently time-series. Aggregation loses signal."]],"caption":"Domains Where Event Sourcing Aligns with Reality","headers":["Domain","Natural Events","Why State-First Feels Wrong"]},"type":"table"},{"data":{"content":"**Signs That Event Sourcing Is a Good Fit**\n\n1. **Domain experts think in events**: When stakeholders naturally say \"when X happens, then Y\" rather than \"X is set to value V\", the domain is event-oriented.\n\n2. **Audit requirements**: Any domain where \"who did what, when, and why\" must be answerable is a candidate.\n\n3. **Temporal questions matter**: If the business needs to answer historical questions, event sourcing provides this intrinsically.\n\n4. **Integration-heavy**: Systems that must notify many downstream consumers benefit from events as the integration mechanism.\n\n5. **Complex state transitions**: When entities go through complex lifecycles with many valid transitions, events capture the actual path taken.\n\n6. **Undo/replay requirements**: Applications needing undo functionality, replay capabilities, or \"what-if\" analysis fit naturally."},"type":"text"},{"data":{"icon":"CheckCircle","title":"The Domain Modeling Insight","content":"Event sourcing often improves domain modeling even beyond the persistence benefits. Thinking about events forces you to capture domain behavior explicitly. Instead of vague 'status changed to active', you have 'AccountActivatedAfterKYCVerification'. This precision reveals business rules and edge cases that state-focused models often miss.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-path-forward","title":"Summary: The Event Sourcing Paradigm","content":[{"data":{"content":"We've established the foundational understanding of event sourcing—why it exists, what paradigm shift it represents, and the principles that make it work. Let's consolidate these key concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**Traditional CRUD destroys information** — Updates overwrite history; state is a lossy compression of what actually happened.","**Events are immutable facts** — They represent things that happened, named in past tense, and can never be changed or deleted.","**State is derived, not stored** — Current state is computed by replaying all events; this computation is deterministic and repeatable.","**Immutability enables trust** — Audit trails, debugging, and temporal queries all depend on guaranteed immutability.","**Corrections are compensating events** — To 'change' history, add new events that logically reverse or adjust previous ones.","**Temporal queries are intrinsic** — Any historical state can be reconstructed by replaying events up to that time.","**Events are a natural integration point** — Downstream systems subscribe to the event stream without polling or coupling.","**Some domains are naturally event-oriented** — Finance, healthcare, logistics, and legal systems model reality as sequences of events."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nUnderstanding that events are the source of truth is the conceptual foundation. The next page dives into the practical engineering: **Event Store Design**. We'll explore how to persist events durably, how to structure event streams, how to handle concurrency and consistency, and the architectural patterns that make event stores performant at scale. The theory becomes implementation."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the paradigm shift event sourcing represents—from storing mutable state to storing immutable events. You've seen why this inversion provides audit trails, temporal queries, debugging capabilities, and integration patterns that traditional persistence cannot match. Next, we'll engineer the event store that makes this possible.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_33f157c4836c3b3859cb0f0f8f6a793c","title":"Event Store Design","order":1,"content":null,"isLocked":true},{"id":"seed_4279b9668a7c2843adc894f257118df3","title":"Rebuilding State from Events","order":2,"content":null,"isLocked":true},{"id":"seed_055b5d8d3e8c3751c10c8f95b235030a","title":"Benefits and Challenges of Event Sourcing","order":3,"content":null,"isLocked":true},{"id":"seed_ea863f9e0664757b9839722e719fb18f","title":"When to Use Event Sourcing","order":4,"content":null,"isLocked":true}]}}