Think of what happens, when you put microcache on top of Varnish ESI based cache.
Take the homepage for example. There are several cached objects in Varnish for it, namely:
- homepage itself (full page cache), it will have the default TTL as you set in the backend (long term). It's "partially full page", because it will have
<esi: references instead of actual blocks
- menu ESI block. a navigational menu is already a block, this can have different TTL
- cart ESI block, this is private ESI block and it varies by some cookie
When you apply microcache to this, on level of NGINX you have no idea which portion of the HTML is meant to be cached based on a cookie (worst case) and which should simply have smaller TTL.
It's doable at least if you vary your microcache by X-Magento-Vary to distinguish between different states/users.
In most of the sense, you have to realize that NGINX micro caching against Varnish setup will bring almost no benefit. If you cache no-cookie case, then all your speedup is the time it takes for Varnish to assemble ESI blocks, which are already all cached. Mostly same applies if you microcache by cookie value.
The one possible benefit to micro cache there would be reducing NGINX overhead of buffering responses from Varnish, especially so in a CDN setup with multiple NGINX-es.