الاستعلامات التفاعلية ومخازن الحالة

Stateful operations like aggregations and joins keep their data in state stores — local key-value stores backed by changelog topics for fault tolerance.

Normally results flow out to a topic, but they also live right inside your app.

Interactive Queries (IQ) let your application read those local state stores directly — no extra database, no re-consuming a topic.

Your streaming app effectively becomes a queryable materialized view.

To query a store you must name it during materialization.

After the app is running, fetch a read-only view of the store from the KafkaStreams instance.

Once you have the store, query it like a map.

State is partitioned across app instances. A given key lives on only one instance.

If you query the wrong instance, you won't find the key — so the app needs to know who owns each key.

Kafka Streams can tell you which instance hosts a key, given the store name and key serializer.

Set application.server so each instance advertises its host and port. This metadata powers cross-instance routing.

A typical pattern: wrap the app in an HTTP server. On a request, find the owning host. If it's local, read the store; otherwise proxy to the remote instance.

During rebalances, stores may be migrating and temporarily unavailable, raising InvalidStateStoreException.

• Retry with backoff.
• Check KafkaStreams.State.RUNNING before querying.

Interactive Queries shine when you want:

• Low-latency reads of aggregated state.
• To avoid a separate serving database.
• A self-contained, scalable materialized view.

For complex ad-hoc queries, a dedicated store may still be better.

You learned Interactive Queries.

• Name a store, then get a read-only handle from KafkaStreams.
• State is partitioned; use queryMetadataForKey to find owners.
• Set application.server and proxy cross-instance requests.
• Handle rebalance exceptions with retries.