Hi Guozhang,

The async event trigger process is not running as a kafka streams application. 
It offers REST interface where other applications post events which in turn 
needs to go through App1's state and send requests to App2 via Kafka. Here is 
the diagram:

   KafkaTopics--->  App1 ---> App2 
                                   |
                                   V
                REST ---->App3

REST API to App3 and read the local store of App1 (IQ) and send requests to 
App2 (through kafka topic, not shown above).  Conceptually it looks same as 
your use case. What do people do if a kafka streams application (App1) has to 
offer REST interface also ?

-thanks
Mohan

On 9/30/20, 5:01 PM, "Guozhang Wang" <wangg...@gmail.com> wrote:

    Hello Mohan,
    
    If I understand correctly, your async event trigger process runs out of the
    streams application, that reads the state stores of app2 through the
    interactive query interface, right? This is actually a pretty common use
    case pattern for IQ :)
    
    
    Guozhang
    
    On Wed, Sep 30, 2020 at 1:22 PM Parthasarathy, Mohan <mpart...@hpe.com>
    wrote:
    
    > Hi,
    >
    > A traditional kafka streams application (App1)  reading data from a kafka
    > topic, doing aggregations resulting in some local state. The output of 
this
    > application is consumed by a different application(App2) for doing a
    > different task. Under some conditions, there is an external trigger (async
    > event) which needs to trigger requests for all the keys in the local store
    > to App2. To achieve this, we can read the local stores from all the
    > replicas and send the request to App2.
    >
    > This async event happens less frequently compared to the normal case that
    > leads to the state creation in the first place. Are there any caveats 
doing
    > it this way ? If not, any other suggestions ?
    >
    > Thanks
    > Mohan
    >
    >
    
    -- 
    -- Guozhang
    

Reply via email to