In an e-commerce application, which data should be modeled as a KTable?

In an e-commerce application, which data should be modeled as a KTable?

• A. Mostly static data like inventory lists, customer lists, and aggregated data like total sales.
• B. Real-time events such as click streams.
• C. Binary large objects like images.
• D. Ephemeral session data.

Answer: (A)

KTable represents a stateful, updatable view of data keyed by a unique key, storing the latest value for each key. This makes it ideal for data you want to keep current and readily query or join with streams. In an e-commerce app, inventory lists and customer lists are exactly the kind of data you want to reflect as a current snapshot: you update the quantity when stock changes or a customer’s information is updated, and downstream processes can rely on the latest state. Aggregated data like total sales per product or category also fits, because you often need a running, current total that other streams can join with or query. Real-time events such as click streams, on the other hand, are best modeled as a KStream since they represent a sequence of events over time rather than a single, latest state per key. Large binary objects aren’t well suited for KTable storage because Kafka topics are optimized for key-value, compacted-state data rather than storing big blobs; you’d keep the BLOBs in external storage and store references in the KTable. Ephemeral session data is transient and not meant to become a durable, long-lived view, so it isn’t a natural fit for a KTable either. So, data that represents a current, queryable state or derived, up-to-date totals are best modeled as a KTable.

KTable represents a stateful, updatable view of data keyed by a unique key, storing the latest value for each key. This makes it ideal for data you want to keep current and readily query or join with streams. In an e-commerce app, inventory lists and customer lists are exactly the kind of data you want to reflect as a current snapshot: you update the quantity when stock changes or a customer’s information is updated, and downstream processes can rely on the latest state. Aggregated data like total sales per product or category also fits, because you often need a running, current total that other streams can join with or query.

Real-time events such as click streams, on the other hand, are best modeled as a KStream since they represent a sequence of events over time rather than a single, latest state per key. Large binary objects aren’t well suited for KTable storage because Kafka topics are optimized for key-value, compacted-state data rather than storing big blobs; you’d keep the BLOBs in external storage and store references in the KTable. Ephemeral session data is transient and not meant to become a durable, long-lived view, so it isn’t a natural fit for a KTable either.

So, data that represents a current, queryable state or derived, up-to-date totals are best modeled as a KTable.