Event sourcing

Store the sequence of events that changed an entity instead of its current state, and rebuild state by replaying them. You get a full audit trail and time travel, but schema evolution and queries need care.

Where it shows up in real systems

  • Event log

    Events are kept for the retention period, so new consumers can replay history. Order is guaranteed only within a partition, and a consumer group can use at most one consumer per partition: partitions cap your parallelism.

    In production: Apache Kafka (Confluent, Amazon MSK), Amazon Kinesis, Redpanda, Azure Event Hubs, Apache Pulsar

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox