How does event sourcing relate to read-optimized state in Kafka, and how does CQRS fit in?

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 the log of changes is the primary store. CQRS (Command Query Responsibility Segregation) is a separate, application-level pattern of using different models for writes (commands) and reads (queries); it is not a Kafka feature and the Apache docs do not define it. The two are independent: you can use CQRS without event sourcing and the reverse, though they are often combined. Kafka serves as the event log, and the read side is built by consuming it. Kafka Streams can turn a stream into a table (a KTable) held in a state store per task, backed by a replicated, log-compacted changelog topic, and Interactive Queries expose read-only queries on those state stores; to query the whole application you must add your own RPC layer, such as a REST API. Alternatively, consumers or Kafka Connect sink connectors can copy the events into an external store such as a search index or database. These read models are updated asynchronously, so reads are eventually consistent with the writes.

Expected key concepts: CQRS, event sourcing, commands, queries, KTable, state store, changelog topic, Interactive Queries, read model, independent, eventually consistent