Explain event sourcing with Kafka. What are the trade-offs?

Event sourcing, as the Kafka docs describe it, is a style of application design in which state changes are logged as a time-ordered sequence of records and that log of changes is the primary store; Kafka's support for very large stored logs makes it a good backend for it. In Kafka, events for an entity are written to a topic with the entity ID as the key, so they land in one partition and stay ordered; current state is derived by replaying them. Advantages: full audit history, the ability to rebuild state or fix bugs by replaying, and natural event-driven integration. Trade-offs to design for: history lasts only as long as retention allows (retention.ms defaults to 7 days; -1 means no time limit), and a log-compacted topic keeps just the latest value per key, so it works as a snapshot or changelog but drops older events. Kafka Streams can materialize events into a KTable or state store (stream-table duality), so reads do not need a full replay. Event schema evolution needs care, and read models are separate from the event log, so reads are eventually consistent.

Expected key concepts: event sourcing, events, replay, audit history, retention.ms, snapshot, KTable, stream-table duality, schema evolution