There isn't a whole lot of need for buffering since we've got all the tweaks in place that make our system as fast as it is, but we do have a couple of levels of buffering incase of network issues, downtime before a replica set member takes over as primary, etc. so that we can try to avoid any isolated failure from slowing down the processing that comes before that point in the work flow.
Working from the end backwards, the first (or last) buffer is a Go buffered channel running within the process on the router which feeds into the database. These channels work as a sort of queue between concurrent Go-routines, or "workers", which have a set amount of allocated space in memory. These are empty most of the time, but if there is a failure with pushing to the database they can start to fill up in order to not block the process before it in the workflow until the system recovers. Before those Go workers on each of the "Router" servers that push to the database is a Redis queue which basically serves as a holding pin in between the CDN servers and the database cluster, which is the data's first stop after leaving it's originating servers.
On those originating servers is the Go process which reads the logs and pushes the data to Redis on the routers, these also utilize buffered channels. So all these layers of buffers work to prevent a block in the workflow during momentary downtimes while the system recovers. However, each of these layers of buffering do have a limit and if they fill up will begin to block on the process before them. In the event of a major failure (such as all members of a replica set being down or the network between the CDN server and the Router being down) the Go process running on the CDN server will stop reading the logs at a position where it lands when it is unable to feed more logs into the channel and hold that position until the channel starts to be drained from the other side and space in the channel becomes available.