A streaming table retains the latest value for each key instead of treating every update as a separate event. In an order-processing architecture, customer data can therefore serve as a current lookup view while orders remain an event stream. section 8.3.6
A stream-table join behaves differently from a stream-to-stream join:
- An incoming order triggers a lookup against the current customer value. section 8.3.6
- A matching key produces an aggregated result; an absent key produces no output. section 8.3.6
- Updating the customer table does not reprocess orders that were already processed. section 8.3.6
Orders with current customer data
Treat payments and orders as streams when their events must meet within a time window. Treat customer data as a table when each order needs only the latest customer value. Matching keys must be processed together, typically through copartitioning; a GlobalKTable can instead broadcast the dataset for read-only lookups without partitioning constraints. section 8.3.6
Figure 8.13 Partitions with the same index are assigned to the same task, and this assignment remains fixed. Elements in input topics that arrive in partitions with the same index will be processed together.
Use the partition-assignment diagram to see why matching keys and aligned partitions keep related records in the same processing task. section 8.3.6
