Hi Pritam, thanks for the comment! I haven’t seen an implementation of stateStore with Redis. So, as far as I know, you’ll have to create your own implementation, which you can absolutely do! You can probably look in the internet if someone created an implementation already.
Great Work, There are very few doing playlists on kafka-streams end-to-end. would have been great, if you could have picked some easier short examples to help out begineers.
Hi Mati! Thanks once again for your videos! Could you please create any example of using Kafka as an interaction system among micro services if possible?)
Hi Mati, great content! I really appreciated your work. I have three questions: 1. noticed in BankBalanceTopology when filter by state==rejected, looks like the stream is's split to two branches, can you explain why we don't nee split().branch() here? 2. when you declare the rejected stream, how does it know which point of the stream it plugs in? this case, look like the order to declare the balance topic and rejected topic doesn't matter. 3. in the second test case, I understand the first balance is 0 and second one is 3000. But for the third one, it should be 3500, why it is 500?
Oh boy, a test! I think I got this: 1. split().branch() would create an either/or condition. We still want to send the rejected transactions to the "bank-balances" topic, it's used for the **latestTransaction** field. So, we always send to "bank-balances" topic, but if it's rejected, we *also* send to "rejected-transactions" topic. 2. because of the first answer, you're correct. Once we have enough information to determine the value of the state (after deserialization), we can filter and send in any order. Think of sending to the "bank-balances" topic and filter/send to the "rejected-transactions" as parallel operations. You can do them in either order. 3. Notice the balanceIDs. In the first (-500) and third (+500) transactions, the balance Id is 1. In the second transaction (+3000) the balance Id is 2. The balance Ids are like account numbers, that's how we keep everyone's accounts separate. The transition happens in BankBalance, the BankBalance.id = bankTransaction.balanceId, then in the topology, the transactions are .groupByKey() and aggregated *by those keys*. Keeping balanceId#2's account safely away from balanceId#1!
As a beginner to Kafka streams I found the explanation really clear. Great explanation Mati Thanks.
Thank you for the information, there really isn't much quality info about streams online so once again thank you and keep up the good work!!!
Thanks Pedro! I'm glad it was helpful to you
Good explanation and well organized videos. Looking forward for more such videos.
Thanks for the feedback! Really appreciated! More videos are on the way!
I miss the words to describe you ,so thank you so much ❤
You are welcome! Thanks for the kind comment!
Awesome explanation 👏
nice explanation. how can we store the bank balances into the redis db using state store, so that we can fetch it whenever required?
Hi Pritam, thanks for the comment! I haven’t seen an implementation of stateStore with Redis. So, as far as I know, you’ll have to create your own implementation, which you can absolutely do! You can probably look in the internet if someone created an implementation already.
Great Work, There are very few doing playlists on kafka-streams end-to-end. would have been great, if you could have picked some easier short examples to help out begineers.
Thanks for your kind comments and your feedback!
Hi Mati!
Thanks once again for your videos!
Could you please create any example of using Kafka as an interaction system among micro services if possible?)
I will! Currently I’m preparing a video on how to scale a stateful application, which is taking me longer than I expected! Thanks for the feedback!
Where is the console-consumer script file?
Hi Mati, great content! I really appreciated your work. I have three questions:
1. noticed in BankBalanceTopology when filter by state==rejected, looks like the stream is's split to two branches, can you explain why we don't nee split().branch() here?
2. when you declare the rejected stream, how does it know which point of the stream it plugs in? this case, look like the order to declare the balance topic and rejected topic doesn't matter.
3. in the second test case, I understand the first balance is 0 and second one is 3000. But for the third one, it should be 3500, why it is 500?
Oh boy, a test! I think I got this:
1. split().branch() would create an either/or condition. We still want to send the rejected transactions to the "bank-balances" topic, it's used for the **latestTransaction** field. So, we always send to "bank-balances" topic, but if it's rejected, we *also* send to "rejected-transactions" topic.
2. because of the first answer, you're correct. Once we have enough information to determine the value of the state (after deserialization), we can filter and send in any order. Think of sending to the "bank-balances" topic and filter/send to the "rejected-transactions" as parallel operations. You can do them in either order.
3. Notice the balanceIDs. In the first (-500) and third (+500) transactions, the balance Id is 1. In the second transaction (+3000) the balance Id is 2. The balance Ids are like account numbers, that's how we keep everyone's accounts separate.
The transition happens in BankBalance, the BankBalance.id = bankTransaction.balanceId, then in the topology, the transactions are .groupByKey() and aggregated *by those keys*. Keeping balanceId#2's account safely away from balanceId#1!
Basically it's like a Map 😂😂😂