Online payment system and Confluent Kafka-Go API

74 Views Asked by At

Recently, I thought of integrating online payment service to my website. All went well until I've got a question regarding its architecture. Well, the service works the following way. First, it checks for any incoming messages that were pushed to kafka topic in the form of payment requests, then it processes these messages asynchronously, and goes back to listening for messages again. I should note that messages are read from the latest offset, which is, in my opinion, not the right way to do it when it comes to payment system, due to the fact that some requests might not be fully processed. Are there any architecture issues in abovementioned scheme? By the way, the service is written in Go and all asynchronous operations are being carried out by goroutines and channels. Here's a snippet

func (kc *KafkaConsumer) Consume(signalChan chan os.Signal) {
    for{
        select{
        case sig := <-signalChan:
            Sugar.Info("Caught signal %v", sig)
            break
        default:
            message, err := kc.Consumer.ReadMessage(-1)
            if err == nil{
                Sugar.Infof("Got a new message %v",message)
                done := make(chan bool)
                go router.UseMessage(*message, done)
                <-done
            }else{
                Log.Error(err.Error())
            }
        }
    }
}

Here, ReadMessage routine reads most recent messages ignoring ones that were sent before. Is it a good approach? Thanks in advance

0

There are 0 best solutions below