liveBook · Manning

KTable

As explained in Kafka for Architects

KTable is a Kafka Streams table abstraction that represents the latest value associated with each key and updates as records change.

A KTable is Kafka Streams’ table abstraction for stateful processing: it represents the current value associated with each key rather than an entire event history. Incoming records update that state, making the abstraction useful when the final state matters more than the sequence of events. section 8.1.3 section 8.3.2

The state is backed by a changelog topic. Kafka Streams uses a compacted topic that retains the latest value for each key, supporting recovery and synchronization without preserving the full history. A table can be converted with toStream() when state changes must be emitted as continuous updates. section 8.3.2

KTables shape several architectural decisions:

  • Use a table when records represent independently changing state, such as customer profiles, rather than only an event sequence. section 8.3.7
  • Treat table-to-table joins differently from stream-table joins: updates to either table can trigger a new result, and no time window is required. section 8.3.7
  • Account for repartitioning and state stores when keys must be aligned before aggregation or joining. section 8.3.7

Keeping a Customer 360 view current

A stream-table join between Transactions and Profiles can leave the aggregate stale: a profile update produces no output unless another transaction arrives. Aggregating transactions into a KTable and joining it with the Profiles KTable makes updates to either side produce a new Customer 360 result. section 8.3.7

Figure 8.15 A pipeline design using Kafka Streams. The source topics, Profiles and Transactions, serve as input streams, while Customer360-enriched is the output topic. Kafka Streams automatically creates intermediate topics for operations like repartitioning and changelog management. Both source topics are converted into tables using state stores, and the resulting tables are joined to produce the enriched output.
A diagram of a diagram of a company

Description automatically generated with medium confidence

Shows the Profiles and Transactions topics converted into tables, joined through state stores, and emitted as Customer360-enriched output, with intermediate topics managed by Kafka Streams. section 8.3.7

How Kafka for Architects covers it

How deep it goes
Explains state stores, compacted changelogs, state updates, conversion to streams, and table-to-table join behavior.
Examples
Uses customer profiles, transactions, regional counters, and a Customer 360 enrichment pipeline to demonstrate table state and updates.
What it assumes
Assumes familiarity with Kafka topics, streaming records, keys, state stores, and serializers and deserializers.
What you can do after
Evaluate/understand when latest-state modeling and table-to-table joins prevent stale aggregates in streaming architectures.
How it connects
Connects KTable with KStream, state stores, changelog topics, repartitioning, aggregation, and table-to-table joins.

Also explained in

Compare how 3 books explain KTable →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kafka for Architects. The section links point to the parts of the book it draws on.