What kinds of joins does Kafka Streams support, and how do they differ at a high level?

## The mental model Kafka Streams has two core abstractions: - A **KStream** is an unbounded sequence of independent events (an append-only log), e.g. clicks or payments. Each record is a fact that happened. - A **KTable** is a changelog: a continuously-updated table where each key maps to its latest value. Later records with the same key overwrite earlier ones (an UPSERT). A **GlobalKTable** is a KTable replicated *in full* to every application instance rather than partitioned across them. Joins combine two of these by **key**. Which combinations exist, and how they behave, follows directly from stream-vs-table semantics. ### 1. Stream-Stream (KStream-KStream) Two unbounded streams have no "current value" to look up, so you join over a **time window** defined by `JoinWindows.ofTimeDifferenceAndGrace(...)`. A record on side A joins every record on side B whose timestamp falls within `[tA - before, tA + after]`. Both sides are buffered in **window stores** (RocksDB state). Supports inner, left, outer. ### 2. Stream-Table (KStream-KTable) For each stream record, look up the table's **current** value for that key and emit the combined result. It is *asymmetric*: only the stream side triggers output; a table update does not re-emit past stream records. No window. Supports inner and left (not outer, because there is no stream record to emit on a table-only change). ### 3. Table-Table (KTable-KTable) Both sides are changelogs. An update on either side looks up the other side's current value and emits an updated result (itself a changelog). Supports inner, left, outer. A **foreign-key (FK) join** (KIP-213) lets the left table join the right table on a key *derived* from the left value, instead of requiring identical keys. ### 4. GlobalKTable joins A `GlobalKTable` holds the entire table on every instance, so the stream side does **not** need to be co-partitioned and can join via a **key-mapper** function (join on any field of the stream value). Only `KStream-GlobalKTable` (inner/left) exists. ### Co-partitioning All non-global joins require the two inputs to be **co-partitioned**: same number of partitions and same partitioning so matching keys land on the same task. GlobalKTable and FK joins are the exceptions that relax this. ### Edge cases - Stream-table joins are sensitive to timing/ordering since they read whatever the table currently holds. - Outer/left joins on streams emit null-paired results only after the window closes (plus grace). - GlobalKTables are bootstrapped fully at startup and are not strictly time-synchronized with the stream side.