Types of communication

1. Request-response : with response times ranging from submilliseconds to a few milliseconds. egs : online transaction processing (OLTP)

2. Batch processing : data is loaded in huge batches once a day, reports are generated, and users look at the same reports until the next data load 
occurs

3. Stream processing :  continuous and nonblocking option , egs : alerting on suspicious credit transactions or network activity (where we can wait 
for the response more than ms but not for one day.)

**Stream processing design patterns : Single-Event Processing, Processing with Local State (we will need this) etc **

VisaNet : 2 steps/Use Cases

1. Authorization service - the client is still waiting for authorization and getting the transaction done
2. Clearing and settlement service (batch processing) - they are not expecting any response. and that is why it is event based streaming

The Authorization happens at the time of purchase, Clearing needs to happen within one day, and settlement happens within 2 days. Which means Authorization is synchronous communication and clearing and settlement can be Asynchronous.

Kafka provides an asynchronous protocol for connecting programs together

Therefore in my opinion, We wont be using kafka in the Authorization service, here we should have some synchronous communication say grpc? And Clearing and settlement service can make use of Kafka.

In my opinion, we will have to design a new kafka system(worst case scenario), leveraging kafka connect to stream data with aerospike. There are some reasons for this :

1. If we use their already existing kafka system, we will be adding to their overhead.
2. They probably want to have newer technology compared to existing kafka implementation(kafka streaming, kafka connect with some nosql DB- say aerospike). In the first use case we will have to design multiple microservices.and make them communicate with each other through kafka or grpc. And then after the transaction store them in our local DB. And this will be later fetched to used to validate in the second phase. In the second use case, we will have to store the clear and settlement data, somewhere. because that piece of data is important. And should be reproducible at any time (that is where i believe Cassandra will be used)

Designing Kafka Stream :

Communication between microservices needs to be based on asynchronous message passing (while logic inside each microservice is performed in a synchronous fashion).

consider Authorization service : It can have the following steps (just an example to demonstrate the design)

1. isUserAuthenticated(UserCardDetails, with otp?) returns true or false: this definitely needs to be grpc, if the result is true move to next step
2. carryOutTheTransaction(UserCardDetails, transaction amount)