Archive old events to cold storage (object storage like S3), keep recent events in the hot event store. New projections start from the most recent snapshot in the hot store and only replay the events since that snapshot. If you need full history replay (regulatory requirements), run it offline in a separate environment during a maintenance window. The key insight: plan archival strategy before you need it. Implement snapshots and tiered storage from the beginning, not as a retrofit.

Aggregates should be designed as consistency boundaries — each aggregate's invariants are protected internally, and cross-aggregate consistency is handled through sagas or workflows. If you need two aggregates to change together atomically, they should be a single aggregate. If they must remain separate for scalability or ownership reasons, use a saga: emit a CrossAggregateReferenceCreated event from aggregate A, have a saga process that event and emit a compensating command to aggregate B, and handle the eventual consistency explicitly. Do not try to use distributed transactions (2PC) across aggregates — that defeats the purpose of having separate consistency boundaries.

Events are immutable once written, so old events must deserialize with new code. Use upcasters: functions that transform old event schemas to the current schema on read. Version your events explicitly in the payload: v1, v2. When the schema changes, add a v2 upcaster that reads v1 events and produces v2 representations. Keep upcasters for all historical versions — never delete old upcasters. Test by replaying events from the beginning of your event store and verifying the final aggregate state matches expected results.

Snapshots are a performance optimization. Without snapshots, reconstructing aggregate state requires replaying all events from the beginning of the aggregate's history. With snapshots, you periodically save the aggregate's state at a given event sequence number. Reconstructing the aggregate loads the snapshot and replays only events after the snapshot sequence. Without snapshots, an aggregate with 10 years of history would be slow to load. With yearly snapshots, you replay at most 1 year of events. Snapshots do not affect correctness — event replay from event 0 always produces the same state. They only affect performance.

Use snapshots as the starting point, then replay only recent events. Take a snapshot at a fixed sequence number (e.g., every 1000 events or yearly). To rebuild: locate the most recent snapshot for the aggregate, load it, then replay only events after the snapshot's sequence number. If snapshots are taken yearly, you replay at most 1 year of events regardless of total history. For aggregates without snapshots or with very long histories, use event archival: archive events older than a threshold (e.g., 2 years) to cold storage (S3), keeping recent events in the hot store. New rebuilds start from the latest hot snapshot and replay only recent events. For regulatory replay that requires full history, run the replay as a separate offline job during maintenance windows, not in the production event store path.

Append-only logging is the storage mechanism: new entries are added, existing entries are never modified or deleted. Event sourcing is the pattern that uses an append-only log to store state-changing events and derives current state by replaying those events. An append-only log can be used for many things (audit logs, transaction logs, message queues) without deriving state from replay. Event sourcing specifically means: the log IS the source of truth, current state is derived by replay, and read models are built by consuming events. The relationship: event sourcing uses append-only logging as its storage mechanism, but not all append-only logs are used for event sourcing.

Use optimistic concurrency with expected version numbers. When loading an aggregate, track its current version. When emitting events, include the expected version. The aggregate root checks: if current version != expected version, reject the command with ConcurrencyException. This prevents two commands from racing on the same aggregate: one succeeds (version matches), one fails (version changed). The failing client fetches the new aggregate state and retries. This is the standard concurrency model for event sourcing aggregates. Implementation: store version as a column on the aggregate record, increment on each event append, check version in the aggregate's command handler before emitting.

Common anti-patterns: using commands as event names (imperative "PlaceOrder" vs past tense "OrderPlaced"), storing too much data in event payloads (include what changed, not entire aggregate state), and not versioning events (breaking changes when schema evolves). Another anti-pattern: creating a separate event for every field change on every aggregate, leading to hundreds of event types that make projections complex. Instead, use coarse-grained events (OrderPlaced with full order snapshot) and let projections extract what they need. Also avoid: rebuilding read models from scratch frequently (use snapshots), storing encrypted binary event data without metadata that enables upcasting (event data should be readable and upcastable, not opaque blobs), and using event sourcing for aggregates that change frequently (event store grows rapidly, rebuild times increase).

Snapshot strategy: save the aggregate's state at fixed intervals (every N events or on a time schedule). Snapshot structure: aggregate ID, version at snapshot time, serialized state, timestamp. To load: find the latest snapshot with version <= target version, load it, replay events from snapshot version + 1 to target version. Trade-offs: snapshots reduce rebuild time but add storage overhead (snapshot per aggregate × snapshot frequency). If you snapshot too frequently (every 10 events), storage overhead is high. If you snapshot too rarely (every 100K events), rebuild time remains high. Find the balance: snapshot when rebuild time would exceed your target (e.g., snapshot every 1000 events if rebuilding from scratch takes 30 seconds but 1000 events takes 1 second). Also test snapshot restoration to ensure snapshot format is backward-compatible across code versions.

The event store is append-only and optimized for append and sequential read by aggregate ID, not for analytical queries (filtering by date range, aggregating across aggregates). For reporting, build read models (projections) that consume events and produce analytics-optimized views: daily revenue summary, user activity aggregation, etc. Query the read models for analytics, not the event store directly. If you need ad-hoc analytics without pre-built projections, either stream events to a separate analytics database (data warehouse, Elasticsearch) or use event store tools that support parallel event streaming for analytics queries (EventStoreDB supports this with category projections). The key insight: event sourcing is not a reporting solution — you build read models for every query pattern you need.

Event sourcing produces events asynchronously: a command succeeds, an event is appended to the event store, an event bus publishes the event, read model consumers process it and update read models. There is a delay between command success and read model reflecting the change — this is eventual consistency. The delay is typically milliseconds in normal operation but can stretch under load. Eventual consistency matters most for user-facing reads immediately after writes (user places order, immediately queries order history). Mitigate by: showing "processing" state in UI, polling read model until caught up, or updating a write-side read model synchronously within the command handler. Eventual consistency is a direct architectural consequence of CQRS with async event propagation — you cannot eliminate it, only manage its UX impact.

Aggregate boundaries define consistency boundaries. A single aggregate's invariants are protected synchronously — changes are atomic within the aggregate. Cross-aggregate consistency is eventual, coordinated by sagas. Choose aggregates based on business invariants: if two entities must always be consistent (e.g., order and order line items), they are likely the same aggregate. If two entities can change independently (e.g., customer and product), they are different aggregates. The rule: if you would need a distributed transaction to update two entities together, they should be one aggregate. If they can be updated independently with eventual consistency between them, they should be separate aggregates. Overly large aggregates (everything in one) create bottlenecks; overly small aggregates (one per entity) create complex saga coordination.

An event store is an append-only log organized by aggregate ID (stream). You write events to a specific stream, and you read events from a stream by aggregate ID. It is persistent and durable — events survive system restarts. A message queue (Kafka, RabbitMQ) is for asynchronous message delivery between services — messages are consumed and typically deleted. Event stores and message queues can be combined: EventStoreDB can publish events to Kafka after writing; Kafka can be the transport for events to read models. Key difference: event store retains all events for replay and audit; message queues are transient. You can rebuild any read model from an event store; you cannot rebuild from a message queue unless you stored the messages elsewhere.

Use upcasters that run during event replay. When a breaking schema change occurs (rename field, change type, split event into two), write an upcaster that transforms old event versions to new versions. Upcasters are registered by event version and run automatically during replay. To migrate in production: deploy new code with upcasters for the old event version; the event store serves old events (with upcasters running), new events are written in new format. This is backward-compatible deployment: both old and new event formats work simultaneously. No downtime migration: event store never rewrites stored events; upcasters handle old events on read. The key rule: never rewrite stored events — only transform them on read.

Correlation ID links related events across aggregates: if a PlaceOrder command triggers an OrderPlaced event, and that triggers a PaymentRequested event, all three share the same correlation ID so you can trace the flow. Causation ID links an event to its immediate cause: the PaymentRequested event has causation ID = the OrderPlaced event ID that caused it. Correlation IDs connect spans of related work across service boundaries; causation IDs describe the direct chain of events within a single workflow. Both matter for debugging: given a PaymentFailed event, you can use correlation ID to find all related events across services, and use causation ID to trace the exact sequence that led to failure. Store both in event metadata: metadata.correlationId = "uuid", metadata.causationId = "previous-event-id".

Event ordering within a single aggregate is guaranteed by sequence numbers — events within a stream are ordered and replay produces deterministic state. Across aggregates, ordering is not guaranteed and should not be assumed. If you need cross-aggregate ordering (e.g., event A must be processed before event B from a different aggregate), you need a saga or workflow coordinator that enforces ordering explicitly. In distributed systems, clocks are unreliable — use logical sequencing (monotonically increasing sequence numbers per stream) rather than wall-clock timestamps for ordering. For distributed event stores (EventStoreDB clustering), use the vector clock or sequence number for conflict detection, not timestamps. If you need total ordering across all events (rare, for strict audit requirements), a single aggregate stream is the only reliable approach — split across aggregates loses ordering guarantees.

Minimum implementation: an events table with columns for aggregate_id, stream (bucket for ordering), event_type, event_data (JSON payload), metadata (JSON for correlation/causation IDs), sequence_number (monotonically increasing per stream), and timestamp. Core guarantees: append-only (no updates or deletes allowed via application code), stream-level sequencing (events within a stream are ordered), and optimistic concurrency via expected_version checks. The append operation must be atomic: write the event and increment the aggregate version in a single transaction. Beyond the minimum, production event stores add: snapshot storage, consumer offset tracking for projections, and event archiving to cold storage.

At 1000 events/day over 5 years: 1.83M events per aggregate. Without snapshots, rebuilding takes minutes to hours. Strategy: snapshot every 10,000 events (roughly every 10 days of activity). This keeps rebuild time to processing 10,000 events = ~10 seconds at 1ms/event. Storage: if an aggregate state averages 10KB serialized, 2 snapshots per aggregate = 20KB per aggregate. For 100K aggregates: 2GB snapshot storage. Alternative: time-based snapshots weekly or monthly regardless of event count. The key metric: target rebuild time should be under 30 seconds — if it takes longer, snapshot more frequently. Always keep at least 2 snapshots (current + previous) so you can verify the latest before promoting it.

Algorithm: load the most recent snapshot (if any) to get the starting state and version; load all events for the aggregate from snapshot_version + 1 to the target version; apply each event in sequence by calling the aggregate's event handler which transitions state; return the final state. If no snapshot exists, start from an empty aggregate and replay all events from version 0. If replaying for a point-in-time (as-of date), filter events by timestamp <= target timestamp and stop there. For full rebuild (no target), replay all events. Performance: use batched event loading (load 1000 events at a time rather than one at a time) and verify snapshots are backward-compatible before deploying new aggregate code.

Aggregate code evolves but old events must still deserialize. Strategy: never delete or rename fields from event schemas; only add optional fields. The aggregate event handler must handle old event versions via upcasters. Upcasters are functions registered by source version that transform old event data to current schema. Example: a OrderPlaced event in v1 has customerEmail; in v2 it is renamed to customerId. The upcaster for v1 reads customerEmail, maps it to customerId, and marks version as 2. The aggregate handler always receives the current version. Test by replaying all historical event versions through the aggregate and verifying final state is correct. Maintain a version test suite that runs after every schema change.