Front-orphaned reverse numbered batching to mitigate cache invalidation
With a standard Plone setup that this site used to have (and for many other systems), one new blog post on this blog would invalidate 250 pages or so, by pushing one blog post off the front page and on to the next "older blog posts >>" page. That in its turn would push one blog post on the the next older page etcetera all the way back to changing 250 pages for the total of 2500 or so blog posts on this blog.
Numbering batches in reverse with the high numbers first, and having the orphans in the beginning rather than the end saves you a lot of cache invalidation.
If you look at the "older blog posts >>" at the front page of this blog you will notice that the numbers in the url for the first page of slightly older posts are very high. That is because the blog posts are numbered backwards.
This saves a lot of cache invalidation when a new blog post is posted. Furthermore, even though the batch size of the site is 10, the front page expands to 19 items before "giving birth" to a new batched page. this means that when a new blog post is made, one page . the front page - is invalidated in the Varnish cache, and not like before, 250 pages.
This blog has about 2500 blog entries as I type this, and you can go back in time, browsing through them with the "older blog posts >>" link. You will get 10 blog posts per page. The url for each batch contains info on what sequence numbers of blog posts you want to see.
However, for some reason it is customary to number these batches starting with newest first. This means that whenever a new item is added to the sequence, every single item gets a new sequence number. Furthermore for aesthetic reasons one does not want to have a small number of posts on the last page (this is called to have "orphans"). So instead the last page is expanded to accommodate for these "orphaned" posts. If you let the first page take care of the orphans, suddenly all your batched pages will be stable forever, barring edits.