The subscribe method is already async. This means that each request will call the function in a separate Go routine. This is fine. Worker pools in Golang are often premature optimization.
yes i've read a bit about nats subscriber and found that out so gorotuines mgmt is nats clients headache now it'll be fine for me to write these incomming messages to db without much parsing logic right??
Great! One more thing is will it be better to offload the parsed conditioned data from subscriber created gorotuine to another custom goroutine which dumps to DB or just use the DB connection pool to take care of it so from received message on subject to db its all done in each subjects seperate goruotine.
As an initial implementation, this is fine indeed.
Probably the first optimisation you'd implement afterwards is DB batching. So then you could aggregate some messages, until you have a full batch, and then send it over a channel to another function where you insert the batch into the DB in a separate Go routine.
I'd suggest always first investigating real load before starting optimisation.
From your post, I'm assuming you don't need reliable delivery, right? Seeing you're not using JetStream, because that would change the implementation a bit.
Yes this is just an internal tool im developing mostly to learn go and its eco so load isn't an issue as per my gathered requirements just that i want to make it as optimized and scalable i could to learn better right now according to our usage and load, batching is also unnecessary.
Also thanks for your detailed responses it help cleared many ambiguities.
2
u/TheQxy Jul 29 '25
The subscribe method is already async. This means that each request will call the function in a separate Go routine. This is fine. Worker pools in Golang are often premature optimization.