It's common for a user action to emit several notifications in quick succession. For instance, pushing a commit will often trigger a notification for the commit, a notification for the revision where it was reviewed, and notifications for one or more tasks which the commit closes. These events happen in rapid succession.
Currently, we'll make a request to the server for each event. This is inefficient, as we pay the per-page startup cost every time. By doing more batching in the pipeline, we can reduce the cost of multiple simultaneous notifications, which are usually responsible for the peak loads the system currently experiences.
Some steps might include:
# Allow the endpoint to take a list of IDs.
# In the client, when receiving lower-urgency notifications (not chat, not objects on the current page), buffer them (for, say, one second) instead of requesting them immediately. After 1 second, send a bulk request for any notifications we've learned about in the meantime.
# Change the Aphlict protocol to support multiple notifications in a single message.
# Change the server to batch the messages it sends (i.e., make only one request at the end of a task or page).
Doing (1) and (2) is likely to have the greatest impact. It might be nice to do (3) and (4) eventually.