6 ms·

We probably both understand the underlying concepts correctly. But just in case: also buffered channels will block if full. So I don't see how notifications ge

• brandur 2y ago
  They'll get lost when using a non-blocking send with select/default: messages := make(chan string) select { case messages <- "hi": fmt.Println("sent message", msg) default: fmt.Println("no message sent") } The reason you'd use a non-blocking send is to make sure that in the event of one slow consumer that the entire system doesn't slow down. Imagine a scaled out version of the notifier in which it's listening on hundreds of topics and receiving thousands of notifications. Each notification is received one-by-one using something like Pgx's `ListenForNotification`, and then distributed via channel to subscriptions that were listening for it. In the case of a blocking send without `default`, one slow consumer that was taking too much time to receive and process its notifications would cause a build up of all other notifications the notifier's supposed to send, so one bad actor would have the effect of degrading the time-to-receive for all listening components. With buffered channels, a poorly written consumer could still drop messages for itself, which isn't optimal (it should be fixed), but all other consumers will still receive theirs promptly. Overall preferable to the alternative.
  • salojoo 2y ago
    Right, I didn't know it was possible to bypass full channels like that with select/default. Thanks for spelling it out